マイクロサービスのデプロイメントに関する課題とは

これまで我々は，Fred George氏，Dustin Huptas氏，Andreas Schmidt氏など何人かの人たちが，マイクロサービスの開発で自らが経験した課題について論じるのを見てきた。先日もUsman Ismail氏が，マイクロサービスの継続的デリバリにおける課題に関するパネルディスカッションに登壇した後，そこでの話題のいくつかをブログで改めて取り上げている。氏の議論は，マイクロサービスの基本的教義に内在する欠点のひとつを指摘することから始まる。それは，ラピッドプロトタイピングやイテレーションでは，大規模なチームほど，よりアジャイルな方法で(ソフトウェアを)移行できるようになる，という点だ。

その一方でマイクロサービスは，運用およびツーリングの面において，開発チームに相当なオーバーヘッドを課すことになります。それぞれのサービスに対して，デプロイメントパイプライン，監視システム，自動アラート(automated alert)，オンコールローテーションといったものが必要になるからです。チームが大規模であれば，こういったシステムを構築する労力に相応する作業上の生産性向上が，このオーバーヘッドをすべて正当化してくれますが，少数の同じ人たちがすべてのサービスに責任を負うような小チームでは，同じようなパイプラインを複数のプロジェクトで用意するというのは，無駄なオーバーヘッド以外のなにものでもありません。

次の問題は運用上のオーバーヘッドだ。氏の見解によると，マイクロサービスあるいはモノシリックアーキテクチャによる開発において，問題の生じたバージョンのサービスないしコンポーネントを排除するには，システムをロールバックする必要がある。リソースに制限がある場合には，それを水平展開すればよい(場合が多い)。しかしマイクロサービスでは，ロールバックの必要なサービスを特定した上で，それに依存する他のサービスへの影響を判断するために，多くのモニタリングやオートメーションが必要になる。

自動アラートを備えているのなら(ぜひ備えるべきですが)，アラートの原因がサービスのオーナに帰するものという考えで，複数のサービスに関するオンコールスケジュールを立てておかなくてはなりません。小規模な組織では，それぞれのサービスの担当者には多くのオーバーラップがあるでしょう。従って，オンコールローテーションから解放される時間をある程度確保するには，同じ人物があまりにも多くのサービスに関連することのないように，これらサービスのスケジュールを調整する必要がある，ということになります。前章までに述べたことに加えて，このような理由からも，多数のマイクロサービスを導入してオーバーヘッドが発生する前に，モノリスの時点ですべてのオペレーション作業を整理しておいた方がよいでしょう。

さらに忘れてならないのは，マイクロサービスの基本的な側面としての分散性(distribution)である。従来のモノシリックなアプリケーションでは，このような問題が存在したとしても，さほど重要になることはない。ここから導かれるのが，分散環境におけるデバッグという昔からの問題，すなわちマイクロサービスという言葉が生まれる前から何度も取り上げられてきた問題だ。JoyentのCTOであるBryan Cantrill氏が以前，実用マイクロサービスのデバッグについて論じたことがある。集中型のログ機構を備えていないことは，マイクロサービスにとって致命的な問題だとIsmail氏は考えている。

さらに言うならば，個別の監視システム(datadog, grahiteなど)，個別のログ集計システム(ELK, loggly, Splunkなど)を持つ大規模システムというのは，現実的ではありません。このスケールでの計測値やログデータの視覚化は，ビッグデータの問題として一箇所で解決すべきです。

パネルセッションで氏が最後に強調したのは，デプロイメントの調整とバージョン管理についてだった。その記事によると，マイクロサービスとモノシリックアプリケーションの大きな違いのひとつは，前者がサービスの依存ツリーであるのに対して，後者がひとつのグラフである点だ。

例えば，モノシリックモデルの典型的なサービススタックは，Webアレイとそこからコールされるキャッシュ層，データベース層，認証などいくつかのスタンドアロンサービス，といった構成を取っています。これに対して，マイクロサービスモデルでは，サービスの相互接続グラフないしネットワークが存在して，それぞれが他のいくつかのサービスに依存しています。非常に重要なのは，このグラフがDAG(有効非巡回グラフ)を維持していることです。そうでなければ依存関係の地獄に陥って，分散スタックのオーバーフローエラーを起こす可能性があります。

興味深いことに，氏の記事はこの後，次のようなパネリストからのガイドラインの要約に続いている。

パネリストの中に，システムを構築する上でのガイドライン的な目的としてのマイクロサービスに，十分に満足している人は誰もいませんでした。それでも私たちは，次のような経験則ないし一般的ガイドラインに到達したのです。

要約は次のようなものだ。

• マイクロサービスの開発とデプロイには，多くのインフラストラクチャが必要となる。ゆえにプラットフォームを使うべきだ。“Kubernetes, Swarm, Mesosといったものが多くをお膳立てしてくれますが，それでもまだ，監視やデバッグ，継続的パイプライン，サービスディスカバリ機構の統合という作業が残っています。”
• 再現性と信頼性の高いオートメーションを実現するためには，人的プロセスによって定義される部分をシステム内に残してはならない。“すべてをコードで定義して，テスト可能，再現可能にしなくてはなりません。例えばサーバ/VMの設定は，docker-machine, puppet, ansibleなどを使ってオーケストレーションされるべきです。”
• 集中型のモニタ，ログ，アラートを開発あるいは利用すること。“モノシリックサービスは愛犬のようなもので，癖や習慣などはすべて分かるのですが，マイクロサービスは家畜のようなものです — ある程度まではすべてを同一視する必要がありますし，個々ではなく全体を群れとして管理しなくてはなりません。”
• 後方互換性と前方互換性を確保すること。
• 大規模なマイクロサービスシステムはネットワークとして可視化すること。“大規模なマイクロサービスシステムの監視と管理は，ネットワークシステムの管理に非常によく似ています。”

これらのレコメンデーションはすべて，さまざまな企業から参加しているパネルメンバたちの経験の集約であると同時に，時間をかけて進化してきたものであり，おそらくは今後も，経験を積み重ねることによって進化していくだろう。氏の最後のコメントは，いくつかの点において，Vijay Alagarasan氏が昨年の“Seven Microsrvices Anti-patterns”講演で語った内容を踏襲している。

[マイクロサービスは]大規模な分散ソフトウェアを構築および運用する上での基本的な問題を解決してくれる，魔法の弾丸ではありません。マイクロサービスアーキテクチャはあなたに，ベストプラクティスと自動化されたワークフローに誠実に従うことを要求します。今回の議論の大きな成果は，機能開発作業からサービスフレームワークの構築とメンテナンスへと，時間とリソースを大きく転換する意思を持たない限り，マイクロサービスの世界に足を踏み入れない方が賢明だ，という結論に達したことです。それでも，もし，優れたサービスフレームワークとワークフローの構築に時間を投資することが可能ならば，よりアジャイルかつ生産的な組織へと変貌を遂げられることでしょう。

我々はマイクロサービスに関して，さらなる経験談を良悪の両面から求めている。Ismail氏の行動や読者自身の論について，コメントしたいことはないだろうか？