・Saga：ローカルトランザクション、イベント、補償トランザクションといった技術や手法を駆使して、複数のリソース間で同期を取るためのデザインパターン。
CQRS(Command Query Responsibility Segregation:コマンドクエリ責務分離)とは、データアクセス処理を、更新系処理(コマンド、すなわちデータの挿入/更新/削除)と参照系処理(クエリ、すなわちデータの検索/取得)に二分し、それぞれの実装にあたって、独立したサービスコンポーネントとデータストアを配すというデザインパターンです(図3.9の上)。その発想の背景には、コマンドとクエリはまったく異なるタイプの処理である、という一種の哲学があります。
■Sagaを実装する2つの手法
・コレオグラフィ：データベースにアクセスするサービスが、それぞれメッセージング製品を介してデータの同期を取り合う方法。
・オーケストレーション：Sagaオーケストレーションと呼ばれる特別なサービスが、トランザクションコーディネーションという役割を受け持つことからアプリケーション層に配置されるアプリケーションサービスとして実装。
■リファクタリングパターンの例
・Anti-corruption layer
Anti-corruption layer (腐敗防止層) は、サービスとモノリス連携において生じる通信プロトコルやアプリケーションプロトコルのギャップを解決するためのマイクロサービスパターンです(4.45)。Anti-corruption layerの仕組みは至ってシンプルで、サービスとモノリスの間に、プロトコルのギャップを解決するためのアダプターを設けるというものです。
たとえば、モノリスがSOAPベースのRPCスタイルのWeb APIを提供していると仮定しましょう。サービスが他のサービス(やモノリス)を呼び出す際には、REST APIやメッセージング等を使うのが、マイクロサービスにおける理想形です。また、前項で説明したように、サービスがモノリスに依存することは避けたほうがよいでしょう。
そこで、Anti corruption layerを活用することにします。「腐敗防止」のためにアダプターコンポーネントを開発して配置します。このアダプターには、サービスから呼び出されるインターフェースとしてREST API、そしてREST API呼び出しを受けてSOAPを介してモノリスのWeb APIを呼び出す機能を実装します。さらに、RESTとSOAPベースのRPCの間でアプリケーションプロトコルを変換するロジックも組み込んでおきます。このようなアダプターを設けることでサービスがモノリスに依存することなく、両者が連携できるようになります。
・Strangler application
次に、クラウドネイティブアプリケーションへの移行に役立つマイクロサービスパターンとして、Strangler applicationについて説明します。図4.46は、Strangler applicationパターンを模式化したものです。まずこの図の見方から解説しましょう。一番左側にPoC局面があり、左から右に時間が流れるのに従って、移行局面がリリース1.0、リリース2.0、リリース3.0と進展しています。各局面の中の上段にはSystems of Engagement(SoE)、すなわち顧客接点のWebアプリケーションのサプシステム群、下段にはSystems of Record(SoR)、すなわち基幹システムのサブシステム群が配置されています。バックグラウンドが白い長方形はモノリシックなサブシステム、バックグラウンドが黒い長方形はマイクロサービス化されたクラウドネイティブサブシステムを表現しています。
移行作業はPoCから始まります。PoC局面ではSoEとSoRの一番右側のサブシステムの一部を、マイクロサービスを利用してクラウドネイティブ化します。それと同時に、SoEとクライアントの境界である図4.46の上段部分にStrangler Podを開発/配置します。Strangler Podとは、業務アプリケーションのメニュー画面をWebアプリケ ーションとして提供する、いわばポータルシステムです。 エンドユーザーは、Strangler Podの提供するメニュー画面で業務名をクリックすることで特定のアプ リケーションを利用するのです。
そこで、Strangler applicationパターンでは、各局面の移行作業が終わったら、アプリケーションへのリクエストがマイクロサービス化されたサービスにルーティングされるように、Strangler Podのメニューアイテムが指し示すURIを書き換えます。このような仕組みを用意しておくことで、移行作業後すぐにサービスをリリースし、エンドユーザーに使ってもらうことが可能になりますし、プロジェクトのスポンサーである経営陣にも、具体的な成果を示すことができます。
また、新規リリースされたクラウドネイティブアプリケーションに障害があった場合には、Strangler Pod上のメニューアイテムが指し示すURIを既存の現行アプリケー ション向けのものに書き換えることで、簡単に実績あるモノリシックアプリケーショ ンに切り戻すことが可能です。
以上のプロセスを、リリース1.0、リリース2.0、リリース 3.0と横展開することで、段階的にアプリケーションのモダン化を進めるのがStrangler applicationバターンです。
ちなみに、いささか物騒ですが、Strangleとは「絞め殺す」という意味です。これは他の植物に絡みつき成長するつたやつるなどの植物が、最終的には宿主となっている植物を覆いつくす様を比喩しています。Strangle applicationとは、マイクロサービスがモノリスを置き換えていく様をイメージしたネーミングなのです。
■サーバーレスとは
サーバーレス(もしくはサーバーレスコンピューティング)とは何でしょうか?サーバーレスとは、一言でいうと「サーバー管理を必要としないアプリケーションを構築して実行する」という概念を表したものです。
また、その名前からよく勘違いされますが、コードをホストして実行するために「サーバーが不要になった」わけではありません。サーバーレスとは、サーバーのプロビジョニング、メンテナンス、アップデート、スケーリング、キャパシティ/プランニングに時間とリソースを費やす必要がないという考え方を指しています。そして、これらのタスクや機能は、すべてサーバーレスプラットフォームによって処理され、開発者や運用チームから完全に抽象化されます。
その結果として、開発者はアプリケーションのビジネスロジックを書くことに集中することができます。運用エンジニアは、よりビジネス上で重要なタスクに集中することができます。
■サーバーレスのユースケース
ここまで、サーバーレスの概要やアーキテクチャを中心に見てきました。ここでは、それらサーバーレスの特長を活かしたユースケースをいくつか見ていきましょう。特にサーバーレスが有効なのは、以下のようなワークロードです。
○非同期/コンカレント/独立した作業単位へと並列化しやすいワークロード
○要求の頻度が低い、散発的なワークロード
○スケーリング要件のばらつきが多く、予測不可能なワークロード
○ステートレスで短命なワークロード
○ビジネス要件が頻繁に変化し、開発もそれにあわせた迅速さが求められるワークロード
■サーバレスの制約
・サーバレス固有の制約
ステート管理の煩雑さ
レイテンシの大きさ
ローカルテストの難しさ
・現在の実装による制約
コールドスタート
ツールや実行環境の制約
ベンダーロックイン
