ITコラム

IBM Cloudのマネージド・サービスで実現するマイクロサービス・アプリケーション

2021年10月27日

記事をシェアする:

お客さまの既存システムのモダナイゼーションの取り組みを積極的かつ適切にご支援するために、クラウド化の推進及び実証を有志によるコミュニティー活動が、日本アイ･ビー･エムデジタルサービス株式会社（IJDS）では行われています。本記事では、活動を通して得られた知見と実績をもとに、クラウドネイティブなアプリケーションの1つの実現方法となる、マイクロサービス・アーキテクチャーの採用を検討する際の考慮点と実現方法について考察します。

著者：亀山裕樹
日本アイ・ビー・エムデジタルサービス株式会社デジタル事業部本部長
主に流通業及び自治体のお客さま向けシステム開発に従事。2020年よりIJDSデジタル事業部で、クラウド開発及びモバイル開発をコアスキルとするフルスタック・エンジニア集団を率いている。

IBMは大企業及び中小企業の1200名以上のITエグゼクティブを対象にマイクロサービスの採用状況の調査を行い、その結果を「Microservices in the enterprise, 2021: Real benefits, worth the challenges」（要登録）というレポートにまとめて公開しています。レポートでは、その調査でマイクロサービス化は展開のしやすさやレジリエンス（回復力）の観点で利点があり、マイクロサービス・アーキテクチャーの採用は長期的なトレンドとなると考えている回答者が多くいたこと、その一方で、マイクロサービス化を熟知している専門家が不足している実態やオンプレミスからの移行が難しいとの回答も少なくないことを伝えています。

大企業及び中小企業の1200名以上のITエグゼクティブを対象にマイクロサービスの採用状況の調査結果の図

IBMのクラウド・ジャーニーの4つのフェーズとマイクロサービス化への課題

お客さまのクラウド活用をご支援するIBMのクラウド・ジャーニーは、大きく次の4フェーズから構成されています。

クラウド戦略立案（Advise）
クラウド移行（Move）
クラウド構築（Build）
クラウド管理（Manage）

1つ目のフェーズの「クラウド戦略立案（Advise）」では、目指すべき姿を明確にし、続く2つ目の「クラウド移行（Move）」ではオンプレミスの既存のインフラをクラウドに移行します。3つ目の「クラウド構築（Build）」にてクラウドに最適化したインフラ環境及びアプリケーション開発を行い、最後のフェーズの「クラウド管理（Manage）」にてマルチ・クラウドの運用管理を最適化していきます。

クラウドに最適化されたアプリケーションを開発する「クラウド構築（Build）」を実現する際の選択肢の1つとして「マイクロサービス化」が挙げられます。マイクロサービス化に向いているのは以下のケースです。

業務が確定しておらず、システム構築後に仕様の変更が頻繁に発生することが想定される場合
既存のシステムと連携しつつ、新しいサービスを提供する場合
実装しようとしている機能の独立性が高い場合

反対に以下のようなケースでは、「マイクロサービス化」のためのワークロードの観点で、効果が見合いません。

システムの規模が小さく、機能数が少ない場合
既に業務が確定しており、今後大きな変化が発生しない場合
システムが従来型の単一のアプリケーションとして開発されたモノリスで既に稼働している場合

これらのケースの他にも、実際にマイクロサービス化されたシステムを運用する場合に多数のサービスの制御、エラー発生時のリカバリー、デプロイの自動化、監視等の考慮が必要となります。これらを実現するためのワークロードと効果のバランスが、マイクロサービス・アーキテクチャーを採用および適用する際の判断基準の1つとなります。

マイクロサービス化を実現するために考えるべきこと

上記のワークロードと効果のバランスと、業務の特性及び複雑さを踏まえた上で、マイクロサービス化が適切と判断した際、実現に向けて考慮すべき点は以下となります。

処理に失敗した際のロールバックも含めて、業務の観点でどのように整合性を担保するかを検討すること
セキュリティーの観点も含めて、管理や運用のワークロードの低減を考慮すること
モノリスに比べサービス間での通信が多くなることから、システム全体としての高応答性を維持すること
マルチクラウド化に適した可搬性が高いアーキテクチャーを選択すること

このようにマイクロサービス・アーキテクチャの採用と実現には様々な観点で考慮する必要があります。本記事では、多数のサービスの制御、エラー発生時のリカバリーの考え方として、「各サービスの呼び出し方」と「トランザクション管理の方法」の２つの軸をご紹介します。

1. サービスの呼び出し方

中央集権型の「オーケストレーション」とイベント・ドリブン型の「コレオグラフィー」

まずは、マイクロサービスを使ってアプリケーションを実装する際の「各サービスの呼び出し方」を考慮する必要があります。サービスの呼び出し方の観点では、中央集権型の「オーケストレーション」とイベント・ドリブン型の「コレオグラフィー」の2つがあります。

サービスの呼び出しの観点で、オーケストラレーションとコレオグラフィーの図

「オーケストレーション」は、各アプリケーションからマイクロサービス化されたコンポーネントが直接呼び出されるアーキテクチャーです。アプリケーションが「指揮者」の位置づけとなり、各サービスを呼び出して一連の処理を順番に実行しています。「コレオグラフィー」はイベンド・ドリブン型で、非同期なイベントを発生させ、各サービスがイベントをサブスクライブし、処理が実行されます。

「オーケストレーション」が「指揮者」が全体のフローを指揮するのに対し、「コレオグラフィー」は「バレリーナ」が予めどのように振る舞うのかが定義されています。事前に定義された振り付けに基づいて「バレリーナ」が舞台上で踊るように各サービスが実行されることから、「コレオグラフィー」と呼ばれています。

「オーケストレーション」は、システムを拡張する際に指揮者となる「オーケストレーションプログラム」を修正する必要があるが、「コレオグラフィー」は各コンポーネントの独立性が高く、修正しやすいという利点があります。

2. トランザクション管理の方法

予約・実行型の「TCC（Try-Confirm-Cancel）」と実行補償型の「Saga」

アプリケーションのトランザクション管理の観点で、予約・実行型のTCC（Try-Confirm-Cancel）と、実行補償型のSagaの２つの方法があります。

TCCは各マイクロサービスのコンポーネント全てに対して予約・実行・キャンセルの3種類のAPIを実装し、ある業務（トランザクション単位）に関わる全てのAPIで予約が成功したことを確認してから確定する手法です。

TCCは正常系を完了させるために「仮の登録」と「確定」という2つの処理をそれぞれ呼び出す必要があります。そのため、処理時間が掛かることがデメリットと言われています。ただし、キャンセルがシンプルに実装出来ることから通販等のシステムではTCCが好まれる傾向があります。

実行補償型のSagaパターンは各マイクロサービスのコンポーネント全てに対して実行・補償の2種類のAPIを実装し、ある業務（トランザクション単位）の途中で処理が失敗した時に今まで実行を行なったAPIに対し、逆処理となる補償のAPIを実行することで擬似的なロールバックを実現する手法です。以下がSagaパターンをコレオグラフィーで実装した場合のイメージとなります。

Sagaでのコレオグラフィー

Sagaパターンを用いるメリットは、正常系の場合、1回のサービス呼び出しで処理を完了できることです。また、サービス間が疎結合になることであるため、柔軟性も高いと言えます。ただし、エラー処理の際に各サービスで補償を実行していく際のトランザクション管理の難易度が高くなるため、複雑なシステムで採用する際には補償時のステータス管理の仕組みを別途検討する必要があります。

マイクロサービスに向いている、サービスの呼び出し方とトランザクション管理の方法

「各サービスの呼び出し方」と「トランザクション管理の方法」の2つの軸で、マイクロサービスを紹介しました。イベント・ドリブン型を基本とするパターンではコレオグラフィーの形式がより自然であることを踏まえると、コレオグラフィーでのSagaパターンが第一候補と考える事もできます。ただし、補償トランザクションの制御が複雑になりすぎないように注意を払う必要があります。処理の複雑さなどに応じてTCCも視野に入れるのが、マイクロサービス化におけるトランザクション管理の望ましい姿と言えます。また、TCCとSagaともに結果整合性となることから、キャンセルまたは補償が完了するまでは正しくないデータとなってしまうことが、業務の観点で許容できるかを検討する必要もあります。

特定のクラウド・ベンダーに依存しない、可搬性の高いマイクロサービス化を実現する

マイクロサービスをクラウドで実現する方法の1つとしてイベント・ドリブンなデザインがあり、その実現方法の1つとして、イベント・ドリブン型のマネージド・サービスの利用が考えられます。

クラウド・ベンダーが提供するIBM Functions/AWS Lambda/ Azure Functions等といったイベント・ドリブン型のマネージド・サービス(FaaS：Function as a Service)を利用する利点は、マネージド・サービスを組み合わせて、早く環境をセットアップ出来ることです。その一方で実装がクラウド・ベンダーに依存するようになり、クラウド・ベンダー間の移行が難しくなるデメリットがあります。ただし、IBM Functions等のイベント・ドリブン型のサービスも近年はコンテナ・イメージ上で稼働ができるようになり、他社のクラウド・プラットフォームに移行するハードルは低くなってきています。

IBM Functions等のクラウド・ベンダーが提供するFaaS以外で、クラウドでマイクロサービス化を実現する方法の選択肢として、KubernetesをベースにKnativeとIstioにてマイクロサービス化を実現する方法があります。Kubernetesを利用することでDockerコンテナ群の管理が可能になり、アプリケーションの展開やコンテナの死活監視等を実現できます。また、Knativeを用いることにより、Kubernetesを使用しFaaSを構築することが可能となります。

KnativeはBuild、Serving、Eventingの3つを提供しています。Servingは、コンテナの迅速なデプロイ、使用しないときはPodをゼロ迄スケールインするオートスケール機能、Istioなどのネットワーク層の設定、コードとコンフィグレーションの管理等の役割があります。Eventingは、イベントをトリガーとし、Kubernetes上で処理を実行可能にします。イベントの発行元と受け手を抽象化し、イベント・ドリブン型のアーキテクチャを実現します。

また、マイクロサービス化を進めると個々のサービスの単位が小さくなり、多数のサービスから構成されるようになります。Kubernetesを含むコンテナ・ソリューションを適用した場合、サービスと同数のコンテナを管理する必要があります。コンテナ間の通信をソフトウェアレイヤーで接続する考えを「サービスメッシュ」と呼びます。Kubernetes単体でもサービスメッシュの機能はありますが、Istioではクラスター内の通信にて、A/Bテスト、カナリア・リリース、パーセンテージ・ベースの段階的なロールアウト等の設定を容易に実現することができます。

Istioでのコンテナ間の通信

クラウドにおけるマネージド・サービスを採用することの利点

IBM CloudはKubernetes、Knative、Istioをマネージド・サービスとして稼働させることができます。さらに、OpenShiftでは、これらを統合したOpenShift Serverlessという1つのサービスとして提供されます。

Kubernetes等のコンテナ技術を採用する際に悩ましいのは、セキュリティー関連で考えるべきことが多いことです。IBM Cloudを始めとするクラウド・サービスは、クラウド・ベンダーが対応すべきことと、ユーザーが対応すべき事を分けて考えることが基本です。マネージド・サービスでKubernetes等のサービスを稼働させることは、独自でこれらのサービスを稼働させる場合に比べて、セキュリティーの観点で検討すべきことが少なく済みます。

またIBM Cloudでは、開発者がアプリケーションの開発に注力できるよう、4月1日より東京リージョン、6月9日より大阪リージョンで、フルマネージド型のランタイムサービスIBM Cloud Code Engineの提供を開始しました。これにより開発者は、アプリケーションのコードを作成すれば、コードのコンテナー化からKubernetes上で稼働させるところまで、IBM Code Engineに任せる事が可能となります。このように、IBM Code Engineを利用することで、ユーザーは本来注力すべきアプリケーションの開発に集中できるようになります。

おわりに

今回はマイクロサービスを適用する際のアーキテクチャーと実現方法の観点で可搬性の高いKubernetesを軸に、KnativeとIstioにてマイクロサービス化を実現する方法をご紹介しました。

本文でも触れていますが、IBM CloudはKubernetes、Knative、Istioの3つのサービス及びOpenShiftをマネージド・サービスとして提供しています。セキュリティーの観点でも、マネージド・サービスの利用は、独自で実装する場合に比べて検討すべきことが少なく済む利点があり、クラウドにて可搬性の高いマイクロサービス化を検討した際に、有力な選択肢の１つになります。