[アーティクル]
10/08/2015

年 9 月 2015

ボリューム 30 番号 9

Azure Insider - 複数のクラウドプラットフォームにまたがる Heroku スタイルの統一ワークフローの作成

Bruno Terkaly | 年 9 月 2015

数年前は、公開直後の Microsoft Azure がメディアに取り上げられることはほとんどありませんでした。ここ数年、この状況が大きく変わっています。これには、マイクロソフトのエンジニアリングチームや大規模コミュニティが大きく貢献しています。この Azure Insider シリーズも、今回からは実際の顧客主体のケーススタディへと視線を移します。

Azure に関する初回のケーススタディとして、Gabriel Monroy にインタビューしました。彼は、目の前のチャンスをまたたく間に 1 つのテクノロジに組み立て、Deis という企業を立ち上げました。同社はすぐに買収され、Monroy は買収先企業の CTO に就任します。あるハッカソンで初めて Monroy と出会い、彼のテクノロジに触れたとき、「買収されるのも時間の問題だ」と話したことを思い出します。これは 2015 年 1 月のことでしたが、その数か月後、立ち上げて間もない彼の会社は、Engine Yard に買収されました。

発明の母

オンプレミスとパブリッククラウドの両方を利用する分散コンピューティングプラットフォームが急激に増え続けています。こうした分散プラットフォームを支えるのは、Linux や Windows などのコンテナー対応の OS、Docker コンテナー、および CoreOS などのクラスター対応版の Linux です。

成功を収めたオープンソースプロジェクトのほとんどは、必要性から生まれたものです。たとえば、仮想マシンの大量のクラスターをセットアップする金融コミュニティに協力し、開発、テスト、運用をサポートしようとするアーキテクトがいるとします。このアーキテクトは、これまで長い間、同じような問題を何度も解決してきました。

まさにこれが Monroy に起こった出来事です。彼は、2005 ～ 2006 年にかけて、金融コミュニティ向けの Linux 開発を行いました。このとき Monroy は当時は新しかったコンテナー化に関するテクノロジをいくつかを利用していました。ほぼ同時期に、Solomon Hykes が Docker の作成に着手しました。事実として、結果的に Monroy は多くの労力を Docker に注ぎ込むことになります。

当時、多くの企業が、開発/テスト/運用のパイプラインを効率化するという共通のニーズを抱えていました。目標は、ソフトウェアを自動的かつタイムリーにユーザーに提供できる状態、つまり継続的インテグレーションの段階まで効率化を進めることでした。

企業は反復可能なプロセスを求めていましたが、そのためのツールはほとんど存在しませんでした。企業は、効率化を開発者任せにしていたといえます。開発者がハードウェアの不足や IT 業務の過酷さを理由に効率化をためらうことを、企業は望んでいませんでした。一方の開発者は、新しい発想や新しいプロジェクトに、繰り返しのためだけの作業を取り込むことを望んでいませんでした。

そこで開発者は代わりとして、不適切なシャドウ IT に手を付け、秘密裏にインフラストラクチャをプロビジョニングし、他者との依存関係から脱却しようとします。また、Amazon Web Services、Digital Icean、Google、Azure などの任意のパブリッククラウドでの運用を求める開発者もいました。必要ならば、自社のデータセンター内でベアメタルでの運用を求めた開発者もいました。

チャンス到来

Heroku は 2007 年終わりから 2008 年初めにかけて、1 つの環境でアプリケーションを開発、テスト、デプロイすることを望む Ruby 開発者に注目し、分散コンピューティングへの新たなアプローチを提案しました。しかし、開発者が重視していたのはアプリケーションで、基盤となるインフラストラクチャではありませんでした。開発者は、アプリケーションとそのデータだけに集中できる基盤プラットフォームを備えた 1 つのコマンドラインインターフェイスを求めていました。可用性、ダウンタイム、障害復旧、デプロイ、運用、必要に応じたスケールアップ/ダウン、バージョン管理などの代表的な問題に悩むことは避けたいとも感じていました。同時に、外部の IT 管理者にワークロードのサポートを要請することにも難色を示しました。このとき、Monroy は最初のチャンスを見い出します。

Monroy は、こうしたアプローチに関係する数々のテクノロジが次々と思い浮かび、起業家としての彼の心に火を付けました。彼は、複数のクラウドプラットフォームで、Heroku スタイルの開発者ワークフローを実現することになります。Monroy のアイデアを実現したテクノロジすべてを詳しく解説する前に、開発者が Deis を使い、仮想のパブリッククラウドで Heroku スタイルのワークフローを満喫できるすばらしい世界を紹介しておきましょう。

以下のコードで Deis プラットフォームをインストールします。このコードは、(オンプレミスまたはクラウドでホストされる) CoreOS Linux コンピューターのクラスターが存在することを前提とします。

# Install Deis tooling
$ deisctl install platform
# Deis platform is running on a cluster
$ deisctl start platform
$ deis register http://deis.example.com

ログインと SSH 証明書に関するわずかなコマンドを考えなければ、開発チームには Deis を利用してアプリケーションのデプロイを始める準備が既に整っています。Deis をインストールしたら、開発者は簡単なコマンドだけを使って、アプリケーションをデプロイし、開発、テスト、運用へと進んでいくことができます。

実現に必要なテクノロジ

Deis と同時期に登場し、Deis を後押ししたいくつかのテクノロジを、図 1 に示します。

図 1 Deis を支えるテクノロジの一覧

コンテナー化は、最近のサーバー側 OS で見られる重要なテクノロジで、最近では Linux でも見られるようになっています。現在の Windows Server には存在しませんが、すぐに使われるようになるでしょう。コンテナー化の考え方は、ホスト OS を、メモリ、CPU、ディスクなどの複数のパーティションに分割することです。1 つの物理 OS を実行する 1 台の物理コンピューターを、複数のコンテナーに分割できます。各コンテナーは相互に独立しているため、アプリケーションは、基本のホスト OS を共有しながら、それぞれのコンテナーで独立して実行されます。

コンテナーは互いに影響を及ぼさず並列に実行できるため、ハードウェアの利用効率が高まります。Linux Containers (LXC) は、CPU、メモリ、ファイル I/O、およびネットワークの各リソースを分離します。LXC は名前空間を含みます。名前空間は、OS とアプリケーションを分離し、それをプロセスツリー、ネットワークアクセス、ユーザー ID、およびファイルシステムに分割します。

Monroy は、LXC が Docker の重要部分になる前の早い時期から LXC を活用しています。その後 Docker が登場し、これが Linux の複数のディストリビューションで標準化されたことで、コンテナー化の考え方が広まりました。実際にコンテナー化が大きく進歩したのは、Solomon が Docker イメージの中央リポジトリを作成したときです。これにより、さまざまな開発者が自由に再利用できる、パブリックに利用可能なコンテナーのエコシステムが実現しました。registry.hub.docker.com (英語) では 14,000 を超えるイメージを利用できます。

考えられるほとんどすべてのパターンのアプリケーションが見つかるので、新たなプロジェクトを迅速に始められます。独自に作成したイメージをこのレジストリを通じて利用可能にすることもできます。そのため、アプリケーションで Nginx や Kafka を使用する場合に、アプリケーションのダウンロードとインストール、システム設定の構成、個別のソフトウェアアプリケーションの特性の一般への告知などを心配する必要はありません。Deis がアプリケーションを Docker イメージとして管理し、Docker コンテナーとしてクラスター間に分散させることができるようにします。以下のように、Docker ファイルを利用して、コンテナー内に独自のアプリケーションを簡単に組み込むことができます。

FROM centos:latest
COPY . /app
WORKDIR /app
CMD python -m SimpleHTTPServer 5000
EXPOSE 5000

Docker ファイルを定義し、クラスター上に Deis をプロビジョニングしたら、アプリケーションのデプロイと管理が、これまで以上に簡単かつ強力になります。Deis を Git ソースコードレポジトリと組み合わせると、デプロイにも管理にも最適になります。アプリケーションのソースコードにも、インフラストラクチャ (Docker コンテナー) 自体にもバージョン管理を使用できます。

このスタイルのアプリケーション開発とデプロイは、反復や予測が可能です。開発、テスト、運用の間の移動が非常に迅速になります。Docker ファイルは、開発、テスト、運用のために、簡易エージェントをサーバーにデプロイします。

# Assume the current folder contains Docker files
$ git add .
$ git commit -m "notes by a developer"
$ git push deis master

Heroku について

Monroy は、Heroku が主に Ruby と Node.js アプリケーションの開発、実行、管理を大きく簡略化できるという理由で、開発者コミュニティに広く浸透していることに気付きました。

開発者は、アプリケーションの開発、インフラストラクチャのプロビジョニング、スケーリングの各作業のあらゆる面を、事実上、一般的なホスト型のコマンドプロンプトを利用して実行できるようになっています。Monroy は、開発者が 1 つの場所ですべての担当作業を完了でき、手に余るほどだった開発者ツールを最小限にできることに感動しました。

バックアップと復元、DNS の構成、ロードバランサーの定義、ディスク使用状況の監視、ユーザーの管理、プラットフォームの記録と監視など、クラスターの運用時に悩まされる多くの管理作業が自動化されます。ノードの追加は、コマンドラインインターフェイスからクラウド構成ファイルの URL を変更するだけで行える簡単な例の 1 つです。クラスターを運用する際に最も重要なのは、フェールオーバーや障害復旧を自動的に含めるなど、クラスターの自己復旧を可能にすることです。

CoreOS

Heroku にはこのカスタムプラットフォームを構築する資金と時間がありましたが、Monroy に必要なのは、負荷分散、監視と警告、フェールオーバーなど、クラスター管理にすぐに使えるソリューションでした。ほぼ同時期に、CoreOS として知られる Linux ディストリビューションの 1 つも、開発者の関心を集めていました。

CoreOS は、Monroy が想像する世界へと進む手助けとなり、不足している部分を完璧に埋めるテクノロジをもたらします。CoreOS はクラスターのデプロイ用に設計されたオープンソースの Linux OS で、自動化、デプロイ、セキュリティ、信頼性、スケーラビリティに重点を置いています。これらはまさに開発者を引き付ける Heroku の特徴と同じです。

CoreOS は間違いなく、Monroy が求めていたソリューションを提供します。CoreOS は普通の Linux ベースの OS ではありません。興味深いことに、CoreOS は Rocket コンテナーランタイムという、Docker コンテナー独自のバージョンの先駆けになろうとしています。

CoreOS は大きな革新をもたらしました。Monroy と彼のチームが最も興味を引かれたのは、etcd、fleet、flannel でした。etce は分散キーバリューストアで、コンピューターのクラスターにまたがってデータを格納する信頼性の高い方法を提供します。この方法は、マスターを含むコンピューターの障害に対応できるようにネットワークをパーティション分割する際に、マスターの選択を適切に処理することで実現されます。クラスターの構成情報を保存する etcd キーバリューストアも、クラスター全体にインテリジェントに分散されます。

使いやすい API のおかげで、この構成ファイル内の値を変更できます。この変更は、その後クラスター内の他のノードに自動的に複製されます。flannel は仮想ネットワークを提供します。この仮想ネットワークでは、各コンテナーのランタイムと共に使用される各ポストにサブネットが与えられえます。これにより、ルーティング可能な一意 IP がクラスター内の各コンテナーに提供されるため、ポートマッピングの複雑性が大幅に緩和されます。

fleet は、クラスターを 1 つの初期システムとして考えることができるようにします。そのため、コンテナーを実行する個別のコンピューターを意識する必要がなくなります。fleet によって、コンテナーがクラスター上のどこかで実行されることを自動的に保証します。そのため、コンピューターに障害が起きたり更新が必要な場合は、fleet ソフトウェアがワークロードをクラスター内の適格なコンピューターに自動的に移行します。

図 2 では、特定のサービスが目標とする状態を fleet に指示するために、クラスターに put 要求を送信できることがわかります。これは、fleet のサービスを作り上げる基盤となるプラミングです。この put 要求によって、クラスターの詳細を意識する必要がなくなります。

図 2 CoreOS の概念図

これで Monroy は Deis の作成に必要なもの (Docker の標準コンテナー化モデルや CoreOS というクラスター対応の Linux バージョン/実装など) をすべて手に入れたことになります。彼は、Heroku をサービスとして提供している企業 Salesforce.com が要求する高額な料金を負担できる開発者だけでなく、さらに多くの開発者に Heroku スタイルの開発を提供できるようになります。

3 つの基本的なコンポーネントは、コントロールプレーン、Docker レジストリ、およびデータプレーンです。これらすべて連携して機能します。開発者は新しいリリースに git push を使い始めています。これは、アプリケーションのソースコードと Docker 構成ファイルの両方を含めることができます。

この新しいビルドは、既存の構成に沿いながら、結果的に新しいリリースになります。その後、このリリースが Docker レジストリにプッシュされます。その後、データプレーンで実行されるスケジューラが、リリースイメージを開発、テスト、および運用へと取り込みます。

この段階で、CoreOS と Deis の両方がコンテナーを管理し、フォールトトレランスやスケーラビリティなどの PaaS (サービスとしてのプラットフォーム) の特徴を提供します。また、データプレーンでは、ルーターがアプリケーションから送信された拒否を受信し、ユーザーを適切なコンテナーに "ルーティング" してその要求を満たします。図 3 は、このように相互に連携するテクノロジを示しています。

図 3 Deis のアーキテクチャ

まとめ

実際に最も成功を収めたオープンソースプロジェクトのいくつかは、無駄な労力を必要としません。そのようなプロジェクトは既存のコンポーネントを使い、それらを 1 つにまとめて、独自の方法でテクノロジに融合します。これが、Monroy と彼のチームが Deis で行ったことです。Docker コンテナー、CoreOS、Heroku スタイルのワークフローの力を結び付けました。チームは Azure だけでなく、オンプレミスはもちろん、さまざまなパブリッククラウドにも Deis を実装しました。

Azure Insider のケーススタディシリーズの次回は、Docker を取り上げます。Docker とは何でしょう。同社がわずか数年の間に数十億ドル規模の企業になり、アプリケーションが開発、テスト、運用と移っていくしくみを変えた理由を説明します。

Bruno Terkaly は、デバイスに依存しない、業界をリードするアプリケーションやサービスを開発できるようにすることを目標にするマイクロソフトのプリンシパルソフトウェアエンジニアです。テクノロジが実現可能かどうかという視点を越え、米国で最高のクラウド商談やモバイル商談を進めることを担当しています。ISV が評価、開発、配置を行う際に、アーキテクチャに関するガイダンスを提供したり、技術的な細かいサポート作業を行うことによって、パートナーがアプリケーションを市場に投入できるようにサポートしています。また、フィードバックを提供したり、ロードマップに影響を与えて、クラウドやモバイルのエンジニアリンググループと密接に連携することも行っています。

この記事のレビューに協力してくれた技術スタッフの Gabriel Monroy (EngineYard) に心より感謝いたします。

Azure Insider - 複数のクラウド プラットフォームにまたがる Heroku スタイルの統一ワークフローの作成