クラウド・ネイティブと
マイクロサービス
クラウドは従来、運用コストの削減や開発スピード向上の観点で推進され、オンプレミスの既存アプリケーションをクラウドへ移行する動きが顕著にみられた。現在はそのような動きだけでなく、オンプレミスのアプリケーションやデータと、AIやブロックチェーンなどのデジタル・テクノロジーを結びつけ、新たなイノベーションを生み出すためのプラットフォームとして利用する動きが出始めている。
そのようななかで、クラウド上で創出される新たな価値をタイムリーに市場や社会に提供するために、最初からクラウド上での稼働を前提とした「クラウド・ネイティブ・アプリケーション」が求められるようになってきた。そして、そのクラウド・ネイティブ・アプリケーションのための実践的なアーキテクチャや開発方法論を整理した新しい考え方が、「マイクロサービス・アーキテクチャ」である。
マイクロサービスは、AmazonやNetflixなどの大規模なクラウドサービス事業者が採用し成功を収めていることから大きな注目を集めている。マイクロサービス・アーキテクチャに対する基本的な理解も、以前と比べて格段に浸透しつつあるように見える。そこで本稿では、マイクロサービスの基本から一歩踏み出し、実際に開発・運用していく際のポイントについて解説する。
モノリシック・アーキテクチャと
マイクロサービス・アーキテクチャ
マイクロサービス・アーキテクチャとは、システムを構成する複数の機能を1つのアプリケーションにまとめる、いわゆるモノリシック（一枚岩）な構成ではなく、システムを複数のマイクロサービス（以下、サービス）の集合体として構成し、サービスとサービスの間をRESTなどの軽量な手段で連携する手法である。さらにこれに加えて、サービスを開発・運用する現場からのフィードバックに基づく各種プラクティスの集合としての面も併せもっている（図表1）。マイクロサービス・アーキテクチャの目的は、モノリシック・アーキテクチャの課題を解決することである。
従来のモノリシックなシステムでは、機能と機能の結び付きが密となるため、アプリケーションの規模や複雑度が大きくなり、1つの機能の変更や追加の影響がその機能だけにとどまらず、ほかの機能にまで及ぶ特性がある。そのため、アプリケーションを迅速に更新できず、1つの機能の障害がシステム全体の障害となり、部分的な負荷の増加に対しても全体をスケーリングする必要があるなど、さまざまな課題が生じる。
一方、マイクロサービスでは、サービスはアプリケーションの機能ごとに分割され、おのおの異なるプロセス上で稼働する。そしてサービス同士はRESTやメッセージングなどの軽量なプロトコルで連携するため、その結び付きは疎となり、機能の変更・追加、障害などの影響を特定のサービス内だけに局所化できる。これによりアプリケーションの更新や障害発生時の問題判別、アクセス数の増減に対するスケーリングなどを迅速に行うことが可能だ。
開発・運用面の課題を解決する
テクノロジーやプラクティス
マイクロサービス・アーキテクチャは、システム構築だけでなく開発・運用面も考慮した方法論である。実際にマイクロサービスを導入するには開発・運用面の課題を解決する必要があるが、これには最新のクラウド・テクノロジーやプラクティスが活用できる。
導入にあたって取り組むべき課題としては、サービスに対する運用負荷の軽減、サービスの迅速かつ継続的な更新、更新に伴うリスクの低減、複数のサービスに対する包括的な監視とログ管理、などが挙げられる。
以下、これらの課題を解決するためのテクノロジーやプラクティスとして、次の4項目について解説する。
・コンテナ
・サービスのデリバリー・パイプライン
・サービスのモニタリングとトレース
・サービスメッシュ
コンテナ
マイクロサービスの実行環境については、ビジネス要件の急激な変化などに対応するためにスピードやポータビリティを考慮する必要があり、現在、その有力な選択肢としてコンテナが注目されている。
コンテナは、オンプレミス／オフプレミスの違いを問わず、コンテナがサポートされる環境であればどこでも同様に動作するので、開発を効率的に進められる。さらに、コンテナをサービス単位で作成すれば、ビルド、デプロイ、リリースをサービス単位で迅速に行える。これらの理由から、コンテナはマイクロサービスの実行環境として最適と見なされている。
現状、コンテナ環境のデファクトスタンダードはDockerである。また、複数のコンテナのデプロイやスケーリングなどをサポートするコンテナ・オーケストレーション・プラットフォームとして、Kubernetesが日に日に注目度を増している。
コンテナの利用は、サービスのポータビリティ向上の観点で有効だが、サービスの設計・実装において、環境に依存する構成要素をコンテナから外部化しておくことや、ログやデータをローカル・ファイルシステムに出力しない、などのプラクティスの適用が重要になることを押さえておきたい。
サービスのデリバリー・パイプライン
マイクロサービス・アーキテクチャでは、モノリシックと比較して、運用管理の対象となるサービスの数は非常に多い。その個々のサービスを迅速かつ安全にリリースするには、デリバリー・パイプラインによる自動化が有効な手段である。
コンテナ（Docker）をベースにしたアプリケーション開発は、一般的に次のような流れとなる。
①開発者の環境に、共通のベースとなるコンテナのイメージを配布する
②開発者は、ベースのコンテナ環境を用いてアプリケーションを開発する
③開発したアプリケーションのソースコードを構成管理のリポジトリに登録する
④ベースイメージ、ミドルウェア、アプリケーションがセットされたコンテナをビルドするためのDockerファイルを作成し、構成管理のリポジトリに登録する
⑤リポジトリ上にあるソースコードからアプリケーションをビルドする
⑥Dockerファイルから、ビルド済みアプリケーションを含むコンテナをビルドする
⑦ビルドされたコンテナをテスト環境にデプロイして統合テストを実施する
⑧統合テスト済みのコンテナをコンテナのレジストリに登録する
⑨統合テスト済みのコンテナをレジストリから取得して本番環境にデプロイする
上記の一連の流れのうち、とくに⑤以降は、CI（Continuous Integration：継続的インテグレーション）ツールを用いたデリバリー・パイプラインによる自動化が可能で、スピーディなサービス開発のために重要である（図表2）。
また、コンテナおよびその開発のためのパイプラインは、マイクロサービス単位で作成・運用することが、サービスの更新を効率的に行ううえでポイントとなる。開発・運用体制についても、同様の理由で、サービス単位で組織することがマイクロサービスでは推奨されている。
サービスのリリースに関しては、本番環境に与えるリスクを低減するための新たなリリース手法が採用され始めている。
「ブルー／グリーン・デプロイメント」は、サービスへのルートの切り替えにより、無停止で新バージョンをリリースする手法である。「カナリア・リリース」は、サービスのトラフィックをコントロールして一部のユーザーのみに新バージョンをリリースし、そこで問題がなければ残りのユーザーに新バージョンをリリースする手法で、万が一、新バージョンで障害が発生した場合でも、その影響を最小限に抑えられる。「A/Bテスト」は、2つのバージョンを並行してリリースし、それぞれのフィードバックを比較する手法である（図表3）。
ただし、これらの手法を適用するには高度なルーティング制御機能が必要になることに留意していただきたい。
サービスのモニタリングとトレース
マイクロサービスでは、１つのシステムを複数のサービスで構成する。そこで、個々のサービスからの情報を集約してシステム全体の稼働状況を把握することが、運用監視や障害対応を行ううえで重要である。ここでは、情報収集、トレーシング、視覚化ツールについて紹介する。
メトリクス情報収集
分散している個々のサービスからリソースの使用状況や実行回数などの情報（メトリクス情報）を収集するにはモニタリングサービス（「Datadog」や「Prometheus」など）を導入し、システム全体をモニタリングする。モニタリングサービスのダッシュボードでサービスの稼働状況を詳細に把握・分析したり、障害発生時に自動でアラートを上げることも可能である。
分散トレーシング
1つのリクエストが複数のサービスの連携によって処理される環境において、問題の判別やレイテンシーを分析するための仕組みが、分散トレーシングである。ユーザーからのリクエストを受け付けた最初のポイントで、リクエストごとに「トレースID（相関ID）」と呼ばれる固有IDを発行し、サービスが連携するときにトレースIDとログ情報を伝播させて、リクエストを追跡する（図表4）。
視覚化ツール
サービスのモニタリングや問題判別のフェーズでは、それらを視覚化し、分析可能な環境を提供するツールも重要である。現在、Webブラウザベースのシンプルな操作性やさまざまな視覚化表現を備えるツールが登場している。それらは、サービス間のコミュニケーション・パターンや依存関係の把握にも有用である。
サービスメッシュ
サービスメッシュとは、サービス間の連携を制御する各種機能を提供するプラットフォームである。サービスメッシュにより、多数のサービスを管理する負荷を軽減したり、カナリア・リリースのような高度なリリース手法を展開できる。
具体的な機能としては、サービス間トラフィックの自動的なロードバランシングや、ルールベースのトラフィック・コントロール、サービス間トラフィックの暗号化・認証、サービス全体に対するポリシーの管理、モニタリングとレポーティングなどがある。
このサービスメッシュを実現するソフトウェアとして注目されているのが、Istioである。Google、IBM、Lyftのジョイント・プロジェクトによるオープンソースで、サイドカー・モデルを採用しているのが特徴である。
サイドカー・モデルとは、オートバイに取り付けられたサイドカーのように、機能がサービスと一体となって稼働するもので、Istioでは「Envoy」と呼ばれるプロキシが各サービスと一緒に稼働し、サービスメッシュとしての機能を提供する。
すなわちEnvoyがサービス間の通信を仲介し、さらに各サービスからの情報を一元管理して全体を制御するコントロールプレーンとも連携して、サービスメッシュ機能を提供する（図表5）。
またサイドカー・モデルなので、サービスのソースコードを修正することなく、Istioのサービスメッシュ機能をシステムに追加できる特徴がある。
＊
以上、マイクロサービスを開発・運用していく際のポイントについて解説した。マイクロサービス・アーキテクチャの開発・運用を成功させるには、課題解決のためのテクノロジーやプラクティスの適用が欠かせない。マイクロサービスの導入を計画しているエンジニアに、これらの取り組みをお勧めしたい。
････････
著者｜古池 範充 氏
日本アイ・ビー・エム
システムズ・エンジニアリング株式会社
クラウド・アプリケーション
アドバイザリーアーキテクト
････････
著者｜飯島 宏太 氏
日本アイ・ビー・エム
システムズ・エンジニアリング株式会社
クラウド・プラットフォーム
ITスペシャリスト
［IS magazine No.20（2018年7月）掲載］
