ニュース
グーグル、Google Cloudで実現するマイクロサービスアーキテクチャを説明
2018年4月28日 00:00
グーグル・クラウド・ジャパンは26日、「マイクロサービスアーキテクチャ」をテーマとしたGoogle Cloudのメディアセミナーを開催した。
マイクロサービスアーキテクチャとは
マイクロサービスアーキテクチャとは、アプリケーションを機能ごとに切り分け、「マイクロサービス」というコンポーネントとして開発するアプローチだ。これに対して、既存のアプリケーションは「モノリス（Monolith：大きな塊や一枚岩）」と呼ばれる。
モノリスに対してマイクロサービスには次のような利点がある。
・機能ごとに異なる技術を採用できる
・アプリケーションを構成する機能を同時進行で開発できる
・コンポーネント単位のため、再利用や置き換えがしやすい
・サービスの全容が把握しやすい
・機能ごとに集中した小さな開発チームで開発できる
耐障害性やアジリティが高く、スケーラブルなアプリケーション開発可能になるため、規模の大きなWebサービスを構築する際には、マイクロサービスアーキテクチャが採用されることが多い。
もちろん、すべてのアプリケーションがマイクロサービスアーキテクチャである必要はない。Google Cloud カスタマーエンジニア 技術部長 佐藤聖規氏は、「マイクロサービスは特性上、ある一定以上の規模のアプリケーションでなければ効果を実感できない。小さなアプリケーションであれば、モノリスの方が効果的なこともある」と述べている。
また、マイクロサービスを支える3つの要素として佐藤氏は、マイクロサービスを実装するコンテナ、アプリケーションを構成するマイクロサービスのコンテナを管理する仕組み（コンテナ管理：オーケストレーション）、さらにユーザーからのリクエストを適切なマイクロサービスに振り分けるロードバランサーを挙げている・
マイクロサービスとコンテナは相性がいい
コンテナは、アプリケーションのコードと、必要なライブラリや設定などをひとつのまとまり（コンテナ）として管理する技術。アプリケーションとインフラが疎結合（緩やかにむすびついた状態）であるため、より柔軟な開発が可能になる。開発環境、テスト環境、本番環境などの移動、オンプレミスとクラウド間の移動などが容易になる。
アプリケーションのコードと依存性をひとつにまとめることから、マイクロサービスとコンテナはとても相性が良い。ただし、コンテナ化すればマイクロサービスになるわけではなく、モノリスをコンテナ化することも可能だ。また、コンテナ以外でマイクロサービスを実装することもできる。
コンテナは仮想マシンと比較されることが多い。仮想マシンは、ホストOSに配置されたハイパーバイザーの上において仮想的なサーバーを構築する技術で、仮想マシンの内部はゲストOSの上にアプリケーションやライブラリ等が配置される。コンテナはホストOS上に配置されたコンテナランタイムの上で稼働する。仮想マシンと比較するとゲストOSもなく軽量でシンプルな構造で、リソースの使用量も少なくコンピュートリソースを細分化して効率的に利用できる。また、さまざまな実行環境に対応するためデプロイメントも容易で、起動も速い。
コンテナを管理する「Kubernetes」
もともとコンテナは1つのサーバー上での利用を前提として開発されているため、複数のノードにまたがったクラスタ環境において、アプリケーションを構成するコンテナを配置するには、コンテナを管理する仕組みが必要になる。
また、単一ノードに配置されている場合であっても、コンテナをひとつひとつデプロイし、起動や停止を手動で管理するのは、規模が大きくなればなるほど困難になっていく。
この課題を解決するのがコンテナ管理（オーケストレーション）ツールで、「Kubernetes」もそのうちのひとつだ。Kubernetesは、オンプレミス／クラウドのいずれでも実行可能で、モダンアプリケーション基盤に求められる要素であるスケーラビリティ、自己修復能力、ローリングアップデート、継続デプロイなどを容易に実行できる。
Googleは15年以上にわたって、検索をはじめとするサービスや製品をコンテナで動かしてきた。コンテナの技術が一般的になる以前から、膨大な数のコンテナを扱ってきた経験があるということでもある。
2014年には、毎週20億以上のコンテナを立ち上げていることが発表されている。Google製品を支えるためのインフラは「Datacenter as "a" Computer」という考え方で運用されている。この"a"がとても重要な意味をもっていて、Googleのデータセンターにある大量のコンピュータを、あたかも1つのコンピュータのように扱うということを表している。つまり、1つの巨大なコンピュータ上で膨大な数のコンテナが稼働し、Googleの製品を構成しているのだ。
そんなGoogleが、コンテナ化したアプリケーションのデプロイおよび管理を行うために開発したのが、コンテナ管理ツール「Borg」だ。その後、GoogleはBorgで培ったコンテナに関する運用知見と技術的知見用いてKubernetesを開発し、2014年にオープンソース化している。
現在Kubernetesは、OSSプロジェクトを扱う「CNCF（Cloud Native Computing Foundation）」で管理されており、2018年3月にはOSSプロジェクトとして成熟したことが認められ、「Graduated Project」に認定されている。
ちなみにKubernetesとは、ギリシャ語で「パイロット」や「操舵手」を意味する単語であるという。
Google Kubernetes Engine（GKE）は、2014年にリリースしたGoogle Cloud Platform（GCP）上で動作するKubernetesのマネージドサービスだ。OSSのKubernetesを利用する場合、ユーザーはKubernetesの環境構築に一定以上精通している必要があるとされている。
しかしGKEを利用すれば、コンテナをクラスタにスケジュールし、ユーザーが定義した要件（CPUやメモリ、実行数など）に基づいて自動的に運用を開始できるという。また、GCP上のさまざまサービスと統合することも可能だ。
ロードバランサー「Google Cloud Load Balancing」
Webアプリケーションを構成するマイクロサービスは、規模が大きくなるほど膨大な数のコンテナを利用することになる。増え続けるマイクロサービスを管理し、ユーザーからのリクエストを適切なマイクロサービスに振り分けるためには、アプリケーションのフロントエンドにロードバランサーが必要になる。
Google Cloud Load Balancing（GCLB）は、リージョンにまたがって負荷を分散することができる。例えば、バックエンドが不調になった場合にはトラフィックを分割してスムーズに移動させたり、自動でクロスリージョン フェイルオーバーを実行したりといったことが可能になる。
さらにGCLBは、ユーザーの接続を、ユーザーに近い場所にあるGoogleのEdge POPで終端し、プロキシされたトラフィックを、ロードバランサーからバックエンドへGoogleのハイパフォーマンスバックボーンを経由して送信する。
画像などの静的なコンテンツをエッジでキャッシュし提供する、といった低遅延を実現することができる。
ほかのクラウドベンダーも、マイクロサービスに関連するさまざまなサービスを提供しているが、マイクロサービスアーキテクチャで構成された大規模アプリケーションをGCP上で動作させる最大のメリットについて、佐藤氏は「コンテナを適切に管理してモダンアプリケーション基盤となるGKEと、ユーザーからのリクエストを適切に分散させるロードバランサーのGCLB、さらにハイパフォーマンス バックボーンを効果的に組み合わせられることにある」と説明した。