段階的移行に必要なテクノロジーとデザインパターン
「今、アプリケーションモダナイズへの関心は非常に高まっている」
こう語り、森氏のセッションは始まった。アプリモダナイズへの関心が高まっている背景には、「データ量や利用者の増加に対応したい」「大幅に増えた保守コストを削減したい」「ブラックボックスを見える化したい」などさまざまな理由があるが、「強調したいのは柔軟かつ迅速に、変更対応が可能なシステムにしたいということ」と森氏は語る。ビジネスで優位に立つには、スピードとアジリティが非常に重要になるからだ。
だが「アプリモダナイズに至る道は険しい」と森氏は言う。「密結合したモノリシックなシステムなので、簡単に分割できそうもない「組織も文化もウォーターフォール開発が前提となっており、そう簡単に変えられない」「モダンな技術や手法を取り入れるのが難しそう」など、アプリモダナイズに取り組みたくても、なかなか踏み切れない理由が多々あるという。
モダナイズへの移行方式は「一括移行」と「段階的移行」の2種類ある。一括移行方式は一度にすべてを移行してしまうため、うまくいけばコストも時間もかからない。だが、後工程でトラブルが発生すると、リカバリーにかかる時間は非常に大きくなる。一方、段階的移行方式であれば、一括移行に比べてトータルコストは高く、工期も長くなるが、難易度やリスクも下がる。しかも小さな効果を確認しつつ導入範囲を決定できるので、「現実的には段階的移行を選択することをお勧めする」と森氏は説明する。
この段階的移行を実現するために森氏は、「マイクロサービス」「コンテナ」「ストラングラーパターン」「イベント駆動型アーキテクチャ」というテクノロジーとデザインパターンが必要になるという。
まずは1つ目の「マイクロサービス」。なぜマイクロサービスが必要なのか。従来のアプリケーションはUI層、ビジネスロジック層、データアクセス層の3層で構成されたモノリシックなアーキテクチャを採用していた。このモノリシックなアーキテクチャのデメリットは、「密結合になっているため、小さな変更であっても層全体でのテストやデプロイのやり直しが必要になる。また1つのデータベースを共有しているために、データが肥大化してボトルネックになりやすいという課題があった」と森氏は説明する。
それに対してマイクロサービスは、UIやビジネスロジック、データアクセスという機能単位で小さなサービスとして定義する。それらの互いに独立した小さなサービス（機能）が連動することで、1つのアプリケーションとして動作するアーキテクチャである。
「従来のモノリシックなアプリケーションとは異なり、サービスが小さく自律的であるため、素早く開発してデリバリーできるのがメリットです。ビジネスのアジリティを上げていくためには、マイクロサービスへと変えていくことが重要になると思います」（森氏）
2つ目の「コンテナ」は、アプリケーションとその動作に必要なライブラリ、依存関係をすべてひとまとまりにパッケージングし、ホストOSの上で独立したアプリケーションとして実行されるものである。コンテナの価値について森氏は3つあるという。1つ目はResource Isolation（リソースと責任の分離）、2つ目はRun Anywhere（環境を意識しない可搬性）、3つ目がImmutable Architecture（アプリケーションの再現性）である。
ここで森氏は「マイクロサービスとコンテナの親和性についても一つ触れておきたいことがある」と言う。ビッグバンではなく、段階的な移行という戦略を採用した場合、アプリケーションの視点において、目指す姿はシステムの透明性が高く改修しやすいアーキテクチャとなり、それを可能にする一つの解がマイクロサービスである。一方で、マイクロサービス化を進めようと、インフラ視点の課題に立ち戻ると、モノリシックなシステムに最適化された標準化が定着しているという現状がある。その結果テクノロジーの変化に適した開発・運用プロセスではないため、小さい単位で頻繁に改修できる基盤の確立を目指していくことになる。
「これを実現するには自ずとコンテナ基盤を採用することになる」と森氏。このようにマイクロサービスとコンテナは非常に相性が良く、「マイクロサービスをコンテナ環境で運用すると、柔軟性などのメリットが得られる反面、動作するコンテナの数が多くなりその管理が複雑になることがある」と森氏。この問題を解決するため、レッドハットではKubernetesコンテナプラットフォーム「OpenShift」を提供している。
3つ目の「ストラングラーパターン」とは、特定の機能を新しいアプリケーションやサービスに徐々に置き換えることで、レガシーシステムを段階的に移行するためのデザインパターンである。レガシーシステムとユーザーのフロントエンドの間に、データを振り分ける役割を担うストラングラーファサードを設置し、ステップごとに一部の機能を切り出してマイクロサービス化し、新しいシステムとして稼働させていくのである。このような仕組みにすることで、「新旧にデータを振り分けることで、ユーザーは新旧を意識することなくシステムが利用できるというメリットがある」と森氏は説明する。このような方法で段階的にすべてのシステムをマイクロサービス化したところで、ストラングファサードを撤去し、移行は完了するというわけだ。
ここで「マイクロサービス化したアプリケーションのデータ連携方式について考えていたい」と森氏。REST（同期通信）のみで構成した場合、どこかのサービスで障害が起こると、機能不全のサービスが下流に向かって発生し、サービス全体が機能不全に陥ってしまう。「リトライ処理や巻き戻しなど、障害時の対応が複雑化してしまう欠点がある」と森氏は指摘する。
イベント駆動型アーキテクチャの採用で、巨大な共有データベースを解体する
この課題に対する回答として、レッドハットが用意しているのが「イベント駆動型アーキテクチャ」の採用である。イベント駆動型のアーキテクチャとは、サービスのAPI呼び出しで連携するのではなく、あるサービスが発行した状態の変化（イベント）を、その変化に興味のあるサービスが反応することで結果的に望ましい連携が行われるというアーキテクチャである。このアーキテクチャを採用するメリットは、「新しい機能やサービスを追加する際に、既存の実装部分にインパクトを与えることなくできること」と森氏は説明する。
こうしたイベント駆動型のアーキテクチャに使えるソリューションとして、最近、注目されているのが「Apache Kafka（以下、Kafka）」である。KafkaはLinkedInで開発され、2011年にオープンソース化されたストリーミングデータのための分散システムである。その特徴は非常に高いスループットと低レイテンシーで大量データを処理できることや、水平スケールがしやすく障害に強いなどが挙げられる。
Kafkaの登場により、イベント駆動型のアーキテクチャの構築が非常に容易になったという。イベント駆動型アーキテクチャを利用した、マイクロサービスのデザインパターンであるCQRS（Command Query Responsibility Segregation：コマンド・クエリ責任分離）もその一例である。CQRSでは検索用にあらかじめ必要なデータ要素をすべて含むJOINテーブルを用意することで、サービスごとに個別のデータベースを実現しつつ、データ連携が可能になる。CQRSの利点は、検索性・応答性と、サービス間の非依存性が向上することだ。
「このCQRSのデザインパターンを発展させる形として、Change Data Capture（CDC）というミドルウェアを活用する考え方もある」と森氏は語る。CDCに対応したミドルウェアを使えば、データベースのコミットログをベースに更新イベントをメッセージブローカーで発行できる。「各サービスは単純に自分が管理する責務のデータベースの更新だけでよくなり、更新イベントを発行するコードを書く必要がなくなる。これによりCQRSのシステムを容易に実現できるのです」（森氏）
CDCにはいくつかの製品が登場している。レッドハットが提供するのが「Debezium」である。DebeziumはKafka Connectを使用したCDCコネクタである。接続したデータベースのトランザクションログを読み取り、それをKafkaメッセージとしてパブリッシュする仕組みとなっている。「データベースで発生したCreateやUpdate、Deleteなどのイベントを他のデータソースに反映させていくことができます」（森氏）
ここで森氏はレガシーシステムの移行の際に課題となる、巨大な共有データベースを解体していく方法を紹介した。
共有データベースを利用する最大の理由は、「強力なトランザクション機能によりデータの一貫性（Consistency）を担保するのが容易であること」と森氏は言う。データの一貫性は整合性（Integrity）と即時性（Timeliness）という2つの要素に分解できる。即時性に対する制約を緩和できれば、トランザクションを使わずにデータの一貫性を担保できるようになるというわけだ。イベント駆動型データ連携システムを用いれば、このような仕組みを実現できるという。
まずはCDCとストリームプロセッシングを採用することで、データパイプラインをバッチ処理ではなく、リアルタイム処理にする。日々更新されるデータはCDCを通してイベントに変換され、一旦、ストリーミングプラットフォームに蓄えられる。そしてこの更新にイベントを使って、逐次データモデルの変更をしながら、そのデータを使用する部署に合わせたデータベースを更新していくという流れにするのである。
「更新されたデータを蓄積するデータベースは必ずしもRDBMSを使う必要はない。検索のために使いたいのであれば、検索に特化したElasticsearchを使うなど、目的に応じて自由に選択できるようになる」と森氏。このような方法でモダナイズを段階的に進めていくことで、最終的に共有データベースは不要になり、イベント駆動型データ連携システムに移行できるという。
最後に森氏はDebezium、Red Hat Fuse、Red Hat AMQ Streamsを使って、イベント駆動型データ連携システムのデモを実施。リアルタイムにデータが連携される様子を披露した。
「モノリシックなレガシーアプリケーションはマイクロサービス化して小さな機能単位に分割し、ストラングラーパターンで徐々に置き換えることで段階的な移行が実現できるのです。そしてイベント駆動型アーキテクチャとCQRSやCDCというデザインパターンを適用することで、巨大な共有データベースと解体すると共に、リアルタイムにデータ連携できるシステムに転換できます」森氏はこう語り、セッションを締めた。
