目次


考え方を変えてクラウドの能力を最大限に引き出す

第 1 回 クラウド・ソリューションと従来の Web アプリとの比較

ベスト・プラクティスを採用することで、クラウドがもたらすメリットを最大限にする

Comments

コンテンツシリーズ

このコンテンツは全#シリーズのパート#です: 考え方を変えてクラウドの能力を最大限に引き出す

このシリーズの続きに乞うご期待。

このコンテンツはシリーズの一部分です:考え方を変えてクラウドの能力を最大限に引き出す

このシリーズの続きに乞うご期待。

Gartner の Thomas J. Bittman 氏は最近のブログ投稿で、140 の顧客を対象に調査を行ったところ、自社のプライベート・クラウド・ソリューションに十分に満足していると回答したのはわずか 5 パーセントであったと明かしています。興味深いことに、残りの「満足していない」95 パーセントの回答者のうち、クラウド・テクノロジーを不満の原因としているのは 6 パーセントだけでした。他の回答者が抱えていた不満の根本原因は、クラウドについての理解が足りず、彼らのビジネスにクラウドがどのようにメリットをもたらし得るかを把握していないことにありました。別の言葉で言い換えると、自社のアーキテクチャー (ビジネス、アプリケーション、情報、インフラストラクチャー) と IT (運用、サポート、管理、ガバナンス) を、クラウド・モデルとこのモデルに関連する事項に適応させる上で問題が生じていたのです。

クラウド対応ソフトウェアとは?

クラウドのコンテキストでは、クラウド内で実行されるアプリケーション (一般には、ソフトウェア) を識別するためにさまざまな用語が使われています。「クラウド対応ソフトウェア」という言葉の標準的な定義はありませんが、「クラウド対応ソフトウェア」とは、当初は従来のデータ・センターにデプロイする目的で開発されたものの、ほとんどあるいはまったく変更を加えずにクラウドへ移行されたソフトウェアとして定義することができます。この記事では、「クラウド対応」という言葉 (一般に「クラウド・ネイティブ」あるいは「クラウド・セントリック」という言葉が使われたりもします) を、クラウド・インフラストラクチャーの基礎を成すテクノロジーを利用することが可能な (従って、クラウド・インフラストラクチャー自体の構成要素として動作可能な) アプリケーションやソフトウェアを表す言葉として使用します。

この意味では、クラウド対応ソフトウェアとは、設計当初からクラウドの原則に従って開発されたソフトウェア、あるいはクラウドの原則を取り込むために大々的に構築しなおされたソフトウェアであるとも言えます。それではクラウドの原則とは何か、詳しく見て行きましょう。

原則 1: 仮想化を前提とすること

仮想環境は、原則的には現実の環境と同じですが、実際にはデプロイするコンポーネントの粒度に影響を与えます。仮想環境では、スケーリング、リカバリー、構成等々を行う際の作業の単位となるのは、仮想化された作業単位 (仮想マシンまたはコンテナー) であることから、アプリケーションをデプロイする単位は、仮想化された作業単位の粒度に従わなければなりません。

スケーリングやリカバリーが実施されたアプリケーション・コンポーネントや、構成が異なるアプリケーション・コンポーネントは、それぞれ別個の VM またはコンポーネントに割り当てる必要があります。そうしなければ、仮想化による付加価値をフルに活用することはできません。例えば、フロントエンドとバックエンドのコンポーネントを同じデプロイメント単位に含めたとすると、フロントエンドのワークロードが増加したときに、不要なバックエンド・サーバーまで作成されることになってしまいます。

原則 2: クラウドがアプリケーション・フレームワークであること

サービス・プロバイダーが提供するサービスは、VM とコンテナーだけではありません。ファイアウォール、ロード・バランサー、VPN、メモリー・キャッシュ、共有ストレージ、ストレージ複製などのサービスも、サービス・プロバイダーが一般に提供しているタイプのサービスです。通常、これらのサービスはクラウド・ソリューション・プロバイダーのクラウド・インフラストラクチャーのバックボーンを構成し、これらのサービスを中心にクラウド・インフラストラクチャーが最適化されます。

クラウド対応アプリケーションは、この最適化されたインフラストラクチャーを利用するように努めるべきであり、代わりとなる準最適なメカニズムを提供するべきではありません。例えば、すべてのクラウド・プロバイダーは、スケーラビリティーと可用性を提供するために、何らかの形のロード・バランシングを利用できるようにしています。それにも関わらず、独自の内部バランシング・メカニズムを持つミドルウェア・クラスターを挿入し、ソリューション (アプリケーション) 開発運用チームが管理するようにすると、ソリューション全体のコストと複雑さが大幅に増大する可能性があります。その一方で、CSP のロード・バランシング・ソリューションをフル活用するには、デプロイするアプリケーションのコンポーネントを完全にステートレスにして、セッション・データを外部の共有ストレージまたはキャッシュにのみ保存する必要があります。

原則 3: あらゆるところで障害に対するレジリエンシーを確保すること

クラウドでは、VM の存続は保証されません。故障や再起動に対する耐性は、アプリケーション・レベルで確保する必要があります。整合性が欠けたデータや一貫性のない状態にも耐えられるようにして、これらの問題が適切に処理されるようにしなければなりません。存続することが保証されていない VM や、ソリューションの構成要素がランダムに分散されている環境には、複雑なアーキテクチャー・コンポーネント (2PC トランザクションの調整機能を備えたトランザクション・マネージャーなど) では上手く対処することができません (アーキテクチャー・コンポーネントの VM の 1 つが再起動されている場合や、地理的に分散されている別のデータ・センター内でソリューションの構成要素の一部が実行されている場合にどうなるか考えてみてください)。

そのため、あらゆるトランザクションには、対応するトランザクションがアプリケーション・レベルで必要になります。つまり、随時スケーリング可能なメカニズムを用意しなければなりません。このことはデータベースにも当てはまり、結局のところ望まれるのは、アーキテクチャー内に単一障害点を作り出す ACID SQL DB よりも、レジリエンシーが組み込まれた一貫性のあるデータベースの方です。この場合に最終的に必要になるのは、ミドルウェア・レベルでは保証することができないデータの流通性であり、このデータの流通性も同じくアプリケーション・ロジックに組み込まれます。

マイクロサービス・アーキテクチャー

「マイクロ Web サービス (Micro-Web-Services)」という言葉は、Peter Rodgers 博士が 2005年の Cloud Computing Expo で初めて紹介したものです。マイクロサービスには、以下の特徴があります。

  • マイクロサービスは小規模で、1 つの機能だけを実行するように細分化されています (UNIX の哲学「do one thing and do it well (1 つのことを上手くやる)」と同様です)。
  • 管理と運用の負担を軽減する方法として、組織の文化に自動デプロイメントおよび自動テストを採り入れる必要があります。
  • 耐脆弱性システムと同じように、組織の文化と設計原則に「故障」と「障害」の概念を採り入れる必要があります。
  • マイクロサービスは、エラスティックかつレジリエントで、最小限ながらも完全かつ組み立て可能なサービスです。

マイクロサービスとクラウド環境でのその重要性を理解するために、従来の Web (モノリシック) アプリケーションについて見て行きましょう。

通常、エンタープライズ Web アプリケーションを構成する主な要素は、ユーザー・インターフェース (ユーザーのマシン上のブラウザー内で実行される、何らかの形の HTML および JavaScript)、データベース (通常はリレーショナル・データベース内のテーブルで構成されます)、そしてサーバー・サイド・アプリケーションの 3 つです。

このサーバー・サイド・アプリケーションが、ブラウザーからの HTTP リクエストの処理、ロジックの実行、データベースからのデータの取得と更新、ブラウザーに送信する HTML ビューの選択とデータの取り込みをすべて引き受けます。このようなサーバー・サイド・アプリケーションは通常モノリスであり、単一のシステム・イメージ上で実行される、単一の論理的な実行可能プログラムです。そのため、システムに変更を加えるには、サーバー・サイド・アプリケーションの新しいバージョンをビルドしてデプロイするという作業が必要になります。どのような変更にしても、このモノリス全体をビルドしなおしてデプロイしなければなりません。システムをスケーリングするために、例えばアクティブなコピーの数を増やすとしたら、より多くのリソースを必要とする部分のスケーリングだけでなく、モノリス全体のスケーリングが必要になってきます。

この手法は、基礎となるインフラストラクチャーの非効率的な使用につながります。ソリューション専用のインフラストラクチャーを使っているのであれば、この非効率は容認できるかもしれませんが、完全に仮想化された環境の場合のように、複数の同時ワークロードに対応するように物理システムを最適化しなければならないとしたら、たちまち手に負えないものとなる可能性があります。

以下のスケール・キューブに、選択可能な 3 種類のスケーリング・オプションを示します。

スケール・キューブ
3 次元でのスケーリングを表すスケール・キューブの図
3 次元でのスケーリングを表すスケール・キューブの図

「X 軸上のスケーリング」では、アプリケーションの複数のコピー間でワークロードを分割します。通常、これはロード・バランサーの背後またはクラスター・マネージャーの下で行われます。

「Y 軸上のスケーリング」では、アプリケーションを複数の異なるサービスに分割します。各サービスが、密接に関連する 1 つ以上の機能を担当します。

「Z 軸上のスケーリング」では、一連のサーバー間でデータを各レコードの属性に基づいて分割します (「シャーディング」とも呼ばれます)。これは、データベースのスケーリングによく使われる方法です。

マイクロサービス・アーキテクチャーは、この 3 つの次元すべてのスケーリングを利用します。

要するに、マイクロサービス・アーキテクチャー・スタイルとは、1 つのアプリケーションを一連の個別のサービスとして開発する手法です。これらのサービスはそれぞれに固有のプロセスで実行され、サービス同士の通信は軽量のメカニズム (通常は HTTP リソース API) を介して行われます。サービスはビジネス機能を中心にビルドされ、サービスのそれぞれを単独でデプロイすることができます。

マイクロサービスでは、同じデータベース・テクノロジーの異なるインスタンスであろうと、まったく異なるデータベース・システムであろうと、各サービスが専用のデータベースを管理することができます。この手法は「ポリグロット永続化」と呼ばれます。これはモノリスでも使用できる手法ですが、マイクロサービスではそれよりも頻繁に使われています。

ポリグロット永続化
ポリグロット永続化を示す図
ポリグロット永続化を示す図

Netflix、Amazon、eBay などのとりわけ大規模なクラウド・ベースのシステムは、モノリシックなアーキテクチャーからマイクロサービス・アーキテクチャーへと進化しています。

不変サーバー

標準化は、クラウド・コンピューティングの最も重要な要素です。システムをビルドする際のベースとなる標準的なイメージのカタログを厳密に施行するだけだとクラウド環境がサポートされない場合には、そのクラウド環境はたちまち手に負えないものになってしまいます。例えば、障害が発生した仮想マシンをあるカタログ・イメージから再起動するときには、100 パーセント確実に、その仮想マシンと同じコードおよび同じ構成のシステムが再起動されるようにしなければなりません。

このような状況は、従来の環境で問題になりがちです。従来の環境では、サーバーとアプリケーションが別々のグループによって、異なるプロセスを通じて保守されますが、構成要素ごとに最適化を行う必要がある上に、環境ごとにサポートしているアプリケーション・セットが異なっているか、変更プロセスがまだ進行中であるかのいずれかが原因となって、それぞれのシステムが独自の状態になっている (別の言い方をすると、まったく同じでなければならないシステムが、実際には完全な複製にはなっていない) のが一般的な状況です。アプリケーションの構成やコンテンツにおける計画外の変更は、「ドリフト」と呼ばれます。

構成のドリフトは、データ・センター環境におけるソフトウェアやハードウェアの継続的な変更が原因で生じる、運用の当然の結果ですが、これによってアプリケーションの管理が極めて困難になる場合があります。

本番環境では、適切なデプロイメントと構成が絶対不可欠であるため、本番前環境では、管理対象リソースが正しく構成されて、特定の検証済みバージョンのソフトウェアと一緒にデプロイされることを確実にするために、十分な取り組みが行われます。管理対象リソースの構成やコンテンツに対する計画外の変更を検出できなかったり理解できなかったりすると、運用上の失敗のリスクが高くなるとともに、トラブルシューティング作業の妨げになります。

実際のところ、サーバーの構成を完全に管理することは不可能なので、構成のドリフトや稼働中のサーバーに対する予期せぬ変更が生じる可能性は高い確率にのぼります。この問題は、アジャイル開発ではさらに顕著になります。それは、アジャイル開発の手法では継続的デプロイメントを重視するからです。

代わりとなる手法は、灰から繰り返し甦る不死鳥の概念を基にしています。不死鳥の概念を具現化した「不変サーバー」手法では、サーバーが定期的にゼロから作り直されます。デプロイ済みのサーバーが変更されることは決してなく、単に新しい更新済みインスタンスで置き換えられます。必要な変更はベース・イメージに対して行われ、テストされた後に適用されます。その変更が適用されていないサーバーは破棄されて置き換えられます。

この不変サーバー手法がもたらす主なメリットは、サーバーがプロビジョニングされた後は、その履歴に関係なく、サーバーの状態が絶対的に確実になることです。例えば、パッケージを削除するプロセスを考えてみてください。以前にインストールしたパッケージが不要になると、それを削除するのに何段階もの複雑な手順を踏まなければならなくなる可能性がありますが、再びゼロから始めれば、必要なものだけを確実にインストールすることができます。

不変インフラストラクチャーの概念は新しいものではなく、コンテナー全般、とりわけ Docker が最近の大きな話題となったことによって、この概念がより広まっています。不変サーバーの手法によってもたらされる影響もあります (例のごとく、何事にも代償があり、すべてに万能というものはありません)。例えば、インスタンスごとの構成アイテムの数と適用範囲は、最小限に抑える必要があり、実現可能な場合は必ず自動化したテストによって、これらの構成アイテムに対する変更をテストしなければなりません。また、データベース・システムに関する固有の課題もあります。特に、データ永続化には格段の注意を払う必要があります。

まとめ

この記事で説明したとおり、クラウド対応アプリケーションには以下の具体的な特徴があります。

  • クラウド環境によって提供されるランタイム機能を利用するために、仮想化を意識した設計になっています。
  • クラウド・インフラストラクチャーをアプリケーション・フレームワークとして使用し、サービス・プロバイダーによって提供されるアーキテクチャー・パターンを別のアーキテクチャーで無効にするのではなく、提供されたアーキテクチャー・パターンを利用します。
  • 存続性を念頭にビルドされるため、外部ミドルウェアに完全に依存する場合とは対照的に、制御可能な手法を最優先にします。
  • 基礎となる技術リソースを最大限有効に活用するマイクロサービス・アーキテクチャーに従います。
  • ソリューション全体に安定性と予測性をもたらすために、不変サーバーとしてデプロイされます。

今回に続く第 2 回第 3 回では、この記事で説明した選択肢が実際のプロジェクト開発に及ぼす影響を説明し、プロセスの合理化とコストの削減を行うためのベスト・プラクティスを紹介します。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Cloud computing, DevOps
ArticleID=1028982
ArticleTitle=考え方を変えてクラウドの能力を最大限に引き出す: 第 1 回 クラウド・ソリューションと従来の Web アプリとの比較
publish-date=04072016