マイクロサービスに次に来るかもしれない言葉について
2021年9月18日に開催されたXP祭り2021で「マイクロサービスに至る歴史とこれから」という講演をしました。資料は次の通りです。本来は75分ぐらいかかるのを45分で話そうとして、余裕で時間オーバーしてすみませんでした。
テクノロジーとテクニックによる進化の流れ
テクノロジーやテクニックは、ITの改善サイクルを向上させるために進化を続けています。「技術そのもの」であるところのテクノロジーに対して、テクニックというのは「人による技術の活かし方」を示します。なので、基本的にはテクノロジーが生まれ、それを使いこなしたテクニックが登場することになります。
現在、進化中のテクノロジーであるCloud NativeやServerlessを前提としたテクニックを示す用語、つまり、マイクロサービスに次に来るかもしれない言葉というのは、時間軸からすると再来年ぐらいに出てきても良さそうです。というわけで、講演では過去の流れを整理するとともに、現在のテクノロジーの状況を見つつ、次の言葉を探してみたいと思います（あくまでも私観なので、違うよ！という人は、ぜひ教えてください）。
これまでの流れ
Agile（2001年/テクニック）
まずはアジャイルです。アジャイルはマネジメントテクニックにもかかわらず、ITの在り方を変えてしまいました。その仕組みを電車で喩えてみます。
定期的に電車を運行する上で重要なのは上の図の②と③の状態です。
開発チームにとってみれば、②電車が出発し、到着するまでの間は安定した作業が可能です。出発した電車は乗降が許されないため、乗車中の客をちゃんと連れて行くことに集中できます。
一方で、ビジネスチームにしてみれば③次の電車が発車するまでの間、誰を次の電車に載せるのか好きなだけ変えられます。ビジネスの状況に合わせて優先順位を変えるなり、仕様を詰めるなり好きにする。④次に電車が来る時に、きちんと決定していればいいのです。
このようにアジャイルは「②開発作業を安定して行う」と「③ビジネスにおける変更を許容する」というのを定期的なタイムボックスという仕組みで実現しました。マネジメントの基本は「計画し実行する」ですが、そこを全く変えずに試行錯誤に向いた開発プロセスを実現しています。
Cloud（2006年/テクノロジー）
Cloudは仮想化技術を土台にしながら、コンピューティングパワーのサービス化（XaaS）に成功しました。発電機を自家所有するのではなく、発電所の電気を従量課金で買ってくる。Cloud技術の発展によって、その対象となるコンピューティングパワーの形態は大きく進化しました。
特にPaaSと呼ばれる領域では、ミドルウェアやインフラが複雑に絡み合うような機能であってもオンデマンドで購入できます。たとえばRDBであれば、ジオレプリケーションのような複雑な機能もボタン1つです。
かつ、そのDBサービスの立ち上げは「ボタン1つ」だけではなく「コードの実行」でも得られます。インフラ構成がソフトウェア的に制御可能（Infrastructure as Code）ということは、インフラ構成の構築をパラメタを変えながら何度でも実行できたり、バージョン管理ができたりすることを意味します。
これまでエンジニアは機能要件だけをコードを実現しました。クラウド上であれば非機能要件もコードで実現できます。その結果、エンジニアはクラウドによって機能要件も非機能要件も自由にコーディングできるようになったのです。
DevOps（2009年/テクニック）
アジャイルの普及とともに、その対象はインフラや運用の分野にも及びます。2009年に行われたVelocity 2009における講演「10+ Deploys Per Day」では、開発担当者と運用担当者がツール（IsC、CI/CD、メトリクスなど）を共有し、文化（信頼、心理的安全性など）を変えていくことでアジャイルに協業できることをしめしました。
2011年にはNoOpsという言葉が登場します。刺激的な言葉ですが、その意味は「開発者が運用環境に手を入れるとき、ツールを使って自分でやればよく、運用担当者と話す必要がない」というものでした。Netfixのブログ「Ops, DevOps and PaaS (NoOps) at Netflix」では、これを「PaaSの整備」と呼んでいます。
従来のやり方では開発者が作った成果物を運用担当者に引き渡していました。だから、運用担当者は、その受け入れに時間をかけてしました。しかし、DevOps/NoOpsでは、運用作業がすべてツール化/自動化されており、開発者は自らの手で運用環境に手を加えたり、成果物をデプロイすることができます。
Microservices（2014年/テクニック）
アジャイルから始まり、DevOpsがもたらした恩恵をシステム構成として整理したのがMicroservicesです。
Microservicesでは、サービス間の疎結合度を高めます。これによって個別サービスは、それぞれのタイミングでリリースすることができるようになります。それぞれのサービスを管理するアジャイルチームが自分のペースでサービスを改善できることが、巨大なシステム全体の改善速度をあげることにつながります。
この前提がDevOps/NoOpeの発展です。運用作業のツール化や自動化がされていれば、サービスをどれだけ分割してもインフラ構成の管理コストは上がらないのです。
つまり、Microservicesとは巨大システムでアジャイルを機能させる構造のことであり、その構造を支えたのがDevOps /NoOpsです。
これからのための技術
では、マイクロサービスに次に来るような言葉はなんでしょうか？その言葉を支えるテクノロジーがCloud Nativeであり、Serverlessであると考えています。
Cloud Native（2015年/テクノロジー）
Cloud Nativeを推進するCloud Native Computing Foundationでは、Cloud Native Trail MapというCloud Nativeへの道のりを紹介しています。ここではオーケストレーション、サービスメッシュ、ストリーミングについて説明します。
オーケストレーション
Cloud Nativeの中心がコンテナオーケストレーションツールKurbernetesであり、その土台がコンテナ技術です。コンテナは「アプリケーションと、その実行環境をパッケージできる」ことがメリットです。コンテナに入るなら、あらゆる言語・フレームワークが利用可能です。
そのコンテナの実行を管理するのがコンテナオーケストレーションです。コンテナに対して以下のような機能を提供し、数千台・数万台といったコンテナであっても管理が可能になります。
- コンテナへのリソース割り当て
- スケーリング
- 状態監視と復旧
- 環境変数の管理
サービスメッシュ
サービスメッシュは、サービス間の連携を管理するためのツールで、その代表がIstioです。サービス間の連携には以下のような横断的関心事があります。
- 連携先サービスの検出とルーティング
- 通信制御（認証認可、暗号化、流量制限など）
- 障害対応（サーキットブレーカー、リトライ、障害注入など）
- 通信状況のロギング
特にセキュリティや障害対応のようなことを個別サービスが個別実装する無駄ですし、誰かがミスればシステム全体に影響を与えかねません。Microservicesは分割が主眼ですが、サービスメッシュは分割されたサービスを統合するための手法と言って良いでしょう。
ストリーミング
MicroserviceにおけるAPI連携と分散データ管理を進化させうるのが「イベント駆動」です。
そもそも、同期API連携は密結合な手法です。元システムからすると相手のインターフェースを知っている必要があります。イベント駆動の場合、元システムはストリームに対してイベントを流すだけで、その先で誰が受け取って、何をするかを知る必要がありません。もちろん、同期APIは重要な手法ですが、イベント駆動にできる連携は多くあります。
次に分散データ管理ですが、これもイベント駆動であればシンプルな解決ができます。元システムが配信したデータを先システムが都合よく切り取って自分のDBに保存しておけばいいのです。これはCQRSやEvent-Sourcingと呼ばれます。もちろん、全てのデータは対応できませんが、イベント駆動であればマスタもトランザクションも、それなりのユースケースで分散データ管理が可能です。
イベント駆動はリアルタイムでデータの状態を共有できます。基幹システム（SoR）のデータ変更をリアルタイムに外部連携できれば、基幹システムの機能をグッと減らせるようになります。
イベント駆動を実現するためのデファクトスタンダードはApache Kafkaです。Kurbernetesにも最適化されてきており、今後、より注目されていくことでしょう。
Serverless（2015年/テクノロジー）
ServerlessといえばFaaS Serverlessであり、その代表はAWS Lambdaです。ですが、メインで話したいのはコンテナを前提としたContainer Serverlessの進化系であるKubernetes Serverlessです。
具体的にはGCPのCloud RunやAWS App Runner、標準仕様でいえばKnativeやKEDAです。これらのKubernetes Serverlessは、Kubernetesを前提にCI/CD・イベント起動・オートスケールの全てをプラットフォームとして提供しています。コードを書いてGitにいれておけば、そこから先のことが全て自動化されてしまうのです。NoOpsを、そのままプラットフォームにしたものといえるでしょう。
これから
いよいよ本題です。Cloud NativeやServerlessといった技術がもたらそうとしているものを整理しました。
- コンテナによってランタイムの言語やフレームワークの縛りがなくなった
- サービスメッシュによって分割されたサービスの統合を集中管理できるようにした
- ストリーミングによってAPI連携に変わる連携が可能になり、分散データ管理が簡単になった
- ServerlessによってNoOpsがプラットフォーム化された
ただし、2021年現在、未成熟な部分があり、多くの企業は技術が成熟する数年後をターゲットにしたほうがよいです。現時点では、まず以下に取り組むことを強く推奨します（Kubernetesが余裕だよ、という組織は無視してください）。
- Cloud Native Trail Mapにある1.コンテナ化と2.CI/CD
- イベント駆動については非同期処理で問題ない一部システムにおいてマネージドサービスのストリーミングを利用
- 非KubernetesなContainer Serverless（AWS ECS Fargate、Azure AppSeriveなど）で動かす
これらのCloud NativeやServerlessを前提とした新しい言葉は「Event-First」のようなことだと思っています。ただ、もうちょっと要点を突いた言葉になるとは思います。リアクティブは難しすぎで、Data in Motionはイマイチかな...。
さいごに
テクノロジーとテクニックは、課題を解決するために進化をしています。この課題と解決方法を理解しておくと、それらの要素を採用する場合の土台がよくわかります。
たとえば、Microservicesに取り組むならAgileとDevOpsは前提であり、ここに組織が慣れていないなら、実現は不可能です。逆に言えばAgileとDevOpsを実現していけば、自然にMicroservicesになっていきます。だって、それが歴史なのですから。
こうした整理が皆様の役に立てばうれしいです。もし、もっと話を聞きたいとか、質問がある、とかがあれば、どうぞTwitter @yusuke_arclamp にメンションいただければと思います。
