Microservices.com Practitioners Summitは,マイクロサービスを実際に採用した大規模アプリケーションを中心とした,実践者が主導するマイクロサービスのカンファレンスだ。2017年1月31日にサンフランシスコで開催され,UberやNew Relic,Lyft,PayPal,Googleなどからマイクロサービス専門家たちが講演を行なう。
Stripeのエンジニアで“Production-Ready Microservices”の著者のSusan Fowler氏は,このサミットで講演する予定だ。Uberでマイクロサービスの標準化に取り組んでいた氏は,ビジネスクリティカルな数多くのチームにそれを適用して,開発するサービスの信頼性向上を図ってきた。
InfoQはサミットを前にしたFowler氏に会い,マイクロサービスアーキテクチャの採用を成功させる上での技術的,ビジネス的,文化的な課題について議論した。
InfoQ: 多くの組織に現存するシステムと交点を持ち,おそらくは競合もする存在として,マイクロサービスの理想はどのようなものだと思われますか?
Susan Fowler: 交点を持つという意味においては,マイクロサービスアーキテクチャの採用は,多くのソフトウェアアプリケーションにとって自然なステップだと思います。モノレポ(Monorepo,モノリス)はスケールアップが極めて困難であるため,多くの技術的組織では,すでにスケーラビリティの限界(並行性の限界,パーティショニングの限界など)に達してしまっています。さらに彼らは,開発速度の停滞も実感しています。アプリケーションが巨大化し,多数のエンジニアが従事するようになると,モノレポのデプロイや開発は(組織という観点からは)非常に困難なものになるからです。この位置に達してしまったのならば,その先へ進むための最も簡単かつスケーラブルな手段は,マイクロサービスアーキテクチャを採用することです。
同時にこれは,多くの対立が発生する場所でもあります。マイクロサービスの採用は一般的に,ソフトウェアシステムの改革における“次のステップ”と考えられているため,ほとんどのシステムはマイクロサービスを想定せずに設計されています。この事実が,組織のあり方やその他の技術的な問題を数多く発生させるのです。
組織の面で言えば,チーム間のコラボレーションを予め十分に計画しておかなければ,自分たちのマイクロサービスを開発するだけでシステムの他の部分をまったく知らないような,隔離された,まとまりのないチームがたくさん出来上がることになります。さらには,自分たちの開発するマイクロサービスが依存する他のサービスの信頼性や安定性,スケーラビリティをまったく意識しないような,マイクロサービス開発チーム間の信頼の制度的不足に陥ることでしょう。
マイクロサービスのエコシステムにおいては,個別化した運用組織の要員配置や運用が困難を伴うこともあるでしょう(多くの企業がそうです)。その場合には,開発者が自らのマイクロサービスに関する運用業務を引き継げるようにしなくてはなりません(往々にして彼らは,そのような業務に対する習熟や訓練,用意ができていないのです)。
技術面では,他とのコミュニケーションが十分にできないような,意味のない奇妙なマイクロサービスが出来上がる可能性があげられます。分離する前のモノリスではもともと,サービス間のバウンダリや機能といったものが定義されていなかったことがその理由です。
もうひとつ,よく目にする技術的な問題としては,マイクロサービスの基盤となるインフラは極めて高度なものでなければならない,という点があります – モノリシックなアプリケーションを運用していた企業の多くは,そのようなインフラの運用や用意をしていません。
InfoQ: 従来のモノリシックなシステムで経験を積んだ開発者がマイクロサービスへの移行を成功させるためには,何を学ぶことが一番重要なのでしょうか?
Fowler: 企業がマイクロサービスを採用した時,開発者にとって最も重要なのは運用スキルです。今後必要となる可能性が最も高いからです。モノリシックなアプリケーションでは,アプリケーションの開発とメンテナンスを分離することは比較的容易なので,開発(dev)と運用(ops)業務を2つのチームに分割することは難しくありません。マイクロサービスアーキテクチャの場合はそうではありません – 何十,何百,時には何千というマイクロサービスが存在するので,必然的に,マイクロサービス開発チームもそれだけ存在することになります。これらのチームに開発者と運用技術者をそれぞれ用意するというのは,組織として成り立たない話です。さらにマイクロサービスアーキテクチャでは,開発を短期間で終了させることが可能ですから,サービスを運用するために技術者を用意するという技術的正当性は多くありません – サービスを一番よく知っているのは開発者なのですから,彼らが運用するのがベストなのです。
InfoQ: 開発者の新たなスキルの他に,マイクロサービスをサポートする上で発生する文化的あるいは組織的変化というものはあるのでしょうか?
Fowler: とてもよい質問ですが,実は非常に長い答が必要な質問でもあります(私の著書“Production-Ready Microservices”はそのためにあるのですから!)。エンジニアリング組織が行なうべき最も大切なことはただひとつ,十分な安定性と信頼性を備えた高度なアプリケーションプラットフォーム・インフラストラクチャ(マイクロサービスの4階層モデルの第3層)の構築です。
InfoQ: MSAの成功には非常に高いレベルのインフラストラクチャが必要だと,あなたのブログ記事“The Four Layers of Microservice Architecture”にはあります。マイクロサービスは単独ではそれほど役に立ちませんが,システムは何らかの方法で起動しなくてはなりません。レガシシステムからマイクロシステムに移行するために必要なオーバヘッドを正当化するには,どうすればよいのでしょう?
Fowler: 規模の小さな企業では,マイクロサービスアーキテクチャの採用にメリットがあるとは限りません。また,すべての企業がレガシシステムをマイクロサービスに分割すべきだとも思いません。
マイクロサービスが本当にうまくいくケースがいくつかあります。 まずひとつは,アプリケーションないしシステムは比較的複雑だが,機能間の境界が非常に明確なケースです。そのような場合は,マイクロサービスに分割するプロセスでそれほど苦労することはありません(ただし,あなたが述べられたように,必要なインフラストラクチャを用意することができるという条件付きですが)。ですが,これは極めて珍しいケースだと思います。
第2のシナリオは,マイクロサービスの話として多くの技術者や企業で耳にするもの – アプリケーションがこれ以上スケールアップできないという限界に達していて,スケーラビリティの制限からパフォーマンスや安定性に重大な問題が発生している状態です。アプリケーションに何らかの修正を行なうことはもはや不可能で,開発者のベロシティも悲惨なことになっています。驚くほど一般的なこのシナリオでは,マイクロサービスに必要なインフラストラクチャ拡大の正当化など問題外です – インフラを構築するか,さもなければアプリケーションのスケールアップはいずれ不可能になるでしょう。
この記事を評価
- 編集者評
- 編集長アクション