サービス指向開発 - Rafael Schloming氏がマイクロサービス構築から学んだこと

QCon San FranciscoでRafael Schloming氏が“Service OrientedDevelopment”と題して講演し、マイクロサービスに移行する組織はシステムアーキテクチャだけでなく、自らのモノリシックな開発プロセスを分解する方法も探さなくてはならない、と主張した。新たに設立するマイクロサービスチームを社内的な“スピンオフ”のように扱うことで、境界が形成され、自己完結と自立の精神が育まれることになる。このようなチームに対しては、デバッグとデプロイメント、運用中のサービスの監視を効率的に行なうためのツーリングの提供が必要だ。

DatawireのCTOでチーフアーキテクトのSchloming氏の講演は、モノリスをマイクロサービスベースのアプリケーションに移行する作業に着手する場合、最初の疑問は何であるかを、聴衆に問いかけることから始まった。一般的な回答は、“モノリスを分解するにはどうすればよいのか？”、“アプリをマイクロサービスで設計するには？”、“マイクロサービスを活用するには、どのようなインフラストラクチャが必要なのか？”といったものだった。しかし氏は、2013年にDatawireでマイクロサービスアプリケーションを開発した時の経験を引合に出しながら、開発プロセスがベロシティを達成し維持する上で最も重要な -- しかし無視されることが多い -- 疑問は、“モノリシックなプロセスをどうやって分解するか”だ、と主張した。

アプリケーションやサービスを開発する時、デリバリ全体のライフサイクルはプロトタイピング(prototype)、運用(production)、ミッションクリティカル(mission critical)という３つのフェーズに分けられる。プロトタイピングのステージでは安定性がそれほど重要でないため、機能提供のベロシティ(velocity、速度)を高く保つことはそれほど難しくない。しかし、デリバリが運用からミッションクリティカルへと移行するにつれ、安定性確保のためにベロシティはしばしば犠牲にされる。アプリケーション内のすべてのコンポーネントのデリバリプロセスを統一するだけでは不十分である。この場合でも、その安定性とベロシティのトレードオフを強いられることになるからだ。

アプリケーションをマイクロサービスベースのシステムとして開発することにより、複数のプロセスの使用が可能になる – マイクロサービス/製品を開発する個々のチームが、デリバリライフサイクルにおける自分たちの現在のステージに対して、適切なプロセスを自由に選択できるようになるのだ。マイクロサービスは分散開発アーキテクチャだが、多数のさまざまな開発プロセスをそれぞれのベロシティ/安定性トレードオフで同時進行させるという、分散開発ワークフローも可能である。ただし、このような開発体制に移行するには、組織的および技術的な変革が不可欠だ。

組織の観点からは、製品を中心として自己完結し、自立したソフトウェアチームを形成することは極めて重要だ。しかしながら、このようなモノリシックなプロセスからマイクロプロセスへの転換には教育とコミュニケーション、そして委譲が必要である。マイクロサービス製品チームの全員が – ローカルなコーディングから始まり、継続的デリバリパイプラインを通じた運用へのデプロイ、アプリケーション監視まで – すべての開発サイクルに触れることになる。これは一般的に、さらなる教育を必要とする。このような変化を通じて、スペシャリストがジェネラリストになる機会が与えられ、最終的に全体論として、より優れたシステムおよび運用が実現されるのだ。

製品チーム全体で同じ言語を話すことはできないかも知れないが、正しく活用すれば、この衝突がコラボレーションの源泉なる可能性もある。組織内の小チームがシステム全体では大きく重要な部分を担当する場合もあるが、このような自立性は、変化の早い市場環境において効果的にシェアを拡げる唯一の方法だ。チームは目標を達成する上で、他チームに依存する必要がないように努力すべきである。集中化されたアーキテクチャに対する依存の排除はその一例だ(ただし、インフラストラクチャへのセルフサービスアクセスを提供する“ Platform Team”が有益な場合もある)。

組織の変革をマイクロサービスに実装する必要性を概念化する上で最善の方法は個々の製品チームがビジネススピンオフであると考えることだ、とSchloming氏は主張した。既存の開発チームがTwilloやStripe等のサードパーティサービスを使用する場合と同じアプローチで、製品チームは内部のサービスを統合する必要がある。

マイクロサービスの技術的実装に関して、Schloming氏は、デリバリサイクルの各ステージにおける目標を次のように概説した。プロトタイプ – ツールとユーザ双方からの迅速なフィードバック、ユーザ利用と拡大 – 機能追加とユーザ障害の回避、ミッションクリティカル – 安定性の確保。この結果として一般的には、製品が成熟した時に移行可能な(マイクロサービスベースの)並列ワークフローを備えた、単一プラットフォームの運用が実現する。 講演ではライフサイクルの各ステージにおける技術的課題の実例が、下位プラットフォームコンポーネントとしてDocker、Kubernetes、Envoyサービスプロキシを使って実演された。

プロトタイプのステージでは、製品内の実験(A/Bテストや並行リリース(canarying)など)のために組織的バイインを獲得することが課題になる可能性がある。技術的な課題は、マイクロサービスをローカルで実行することだ。これを克服するための戦略は、セルフサービスのプロビジョニングと、継続的デリバリパイプラインを通じてリモート環境にデプロイ可能な開発用コンテナを提供することである。Schloming氏は、Datawireチームが開発したオープンソースツールのforge.sh -- ビルドと依存関係の単一のソースであるポータブルな開発環境を作成する -- と、リモートのKubernetesクラスタにプロキシするtelepresence --リモートサービスと通信するアプリケーションを、あたかもそのクラスタ内で動作するようにローカルで開発可能にするツール(および関連するデバッグツール)を使った実例を示してみせた。

ユーザとシステムが拡張する運用フェーズにおいて重要な問題は、実験によるユーザへの影響を測定すること(およびベロシティと安定性のトレードオフを認識すること)、新機能のテスト、ソフトウェアバグによる影響の緩和などだ。これらの問題は、マルチバージョンデプロイメントを使って克服することができる。(新サービスとしてデプロイされた)新機能を並行リリースして、メトリクス測定による信頼性向上に伴ってトラフィックを徐々に増加させればよいのだ。Matt Klein氏とLyft技術チームが開発し、大規模に運用されているレイヤ7(アプリケーション)プロキシのEnvoyはこの機能を提供し、すべてのトラフィックをこのプロキシを通じてルーティングおよびコントロールすることが可能だ。過去6ヶ月間、Istio(サービスメッシュデータプレーンとしてEnvoyを使用している)の登場により、この概念がにわかに注目されるようになっている。

最後のフェーズ --ミッションクリティカルなソフトウェア -- の課題は、機能の退行回避とアプリケーションの監視性(observability)に関するものだ。これを克服する戦略は、SLO(Service Level Objective)の定義と、レイヤ７の監視性から成り立っている。SLOの作成、契約としてのSLA(Service Level Agreement)の施行を、組織全体の活動として実施する。レイヤ７の監視性は、Envoy(あるいは同等のプロキシ)を通じて実装可能である。ネットワークスタックのこのレイヤでこのプロキシを運用して、ネットワーク内のすべてのサービス間トラフィックにアクセス可能にするのだ。

Schloming氏は、マイクロサービスへの移行に着手する場合、モノリシックなアーキテクチャの分割に加えて、モノリシックなプロセスの分割にも注意を払う必要があると述べて、自身の講演を要約した。効果的なサービス指向開発を実現するためには、マイクロサービス製品チームを自己完結的かつ自立的な“スピンオフ”として組織化することが有益であるとともに、ツーリングの作成が不可欠である。

Rafael Schloming氏の講演“Service Oriented Development”のスライド資料(PDF、2MB)は、QCon SF Webサイトで公開されている。これを含むすべての講演のビデオが、近日中にInfoQで公開される予定である。