7/27/2016

エンド・オブ・マイクロサービス

エンド・オブ・マイクロサービスと題するエッセイ。タイトルからするとミスリードだよなぁ。「マイクロサービスの先」という意味かな。

信頼性があってスケーラブルな生産システムが他のソフトウェアを書くのと同じくらい簡単にできるようになった未来からの投稿。未来がどのようになっているかを知るために読んでほしい。

2016年頃、人々はマイクロサービスについて数多くを書いたが、それは1996年頃に情報スーパーハイウェイについていかに数多く書いたようなものだった。ちょうど情報スーパーハイウェイという表現は徐々に消え、人々はインターネットを構築することに立ち返った。サービスがスケーラブルなソフトウェアシステムを構築する標準的な方法になるにつれ、マイクロサービスのマイクロという部分が落とされた。名前の意に反し、我々は双方の言い回しを、どのように人々がそれについて考えたかの転換を示するのに使った(そして取り残された)。サービス指向アーキテクチャを使うことは、開発者がサービス間の接続にフォーカスすることを意味し、より良いソフトウェアをより早く構築することを可能にした。

Rise fall information superhighway

情報スーパーハイウェイの盛衰(ソース)

2016年以後、開発者は一度に一つのサービスに重点的に取り組むことによって、より生産的になった。サービスとは何? 大雑把に、シンプルに定義でき、独立してデプロイされるソフトウェアの最小の役立つ固まりである。通知サービス、ログインサービスあるいは、永続性のあるKey-Valueストレージサービスを考えてみてほしい。頑丈なサービスは一つだけで、うまくこなす。開発者は仮想マシンあるいは他の低レベルインフラについて心配する必要がなくなったため、速く変化している: サービスは抽象度を上げている (もう一つのバズワード: しばらくの間、サーバーレスコンピューティングと呼ばれた)。そして、サービス間の接続は明確だったため、開発者は総じてアプリケーションについての考えから解放され、むしろ自身の機能やそれが依存するサービスに集中できる。

ずっと昔、多くの組織は「一つのバイナリを10の小さなバイナリに分解する」するつもりで、マイクロサービスアーキテクチャへの移行を考えた。彼らが見つけたものは、10回以上繰り返すだけという同じ古い問題を持っていたことだった。そのうち、彼らは頑丈なアプリケーションを作ることは、単にモノリスを小さな固まりに分解するという問題だけではない、むしろ、これらの固まりの間の接続を理解することだと気付いた。これは正しい疑問を尋ね始めた頃だった: 私のサービスが依存するサービスは何だ? 依存関係が効果がない場合、何が起きるのか? どんなサービスが私のサービスにRPCを作るのか? 私が期待するRPCはどのくらい必要か? これらの疑問に答えることは新しいツール群や新しい見方を要求した。

ツール、ツール、ツール

サービス指向アーキテクチャを作ることは独立して相互接続されるサービスの性質を調整するための新しいツールキットなしには不可能だろう。ツールはサービスをプログラムで表現し、API境界とサービス間の関係を定義する。それらは異なるサービスの相互作用を管理する規約を効果的に定義する。これらのツールはマニュアル、サービスのテストを手助けし、分散アプリケーションの構築と共に多くのひな形を生成する。

もう一つの重要なツールはデプロイを手助けし、サービスをまとめることだ: そのサービスは、高レベルのサービスを彼らが消費する基本リソースにマッピングするスケジューラ(そして、適切にそれらをスケールする)、彼らが行く必要のある場所を得るリクエストを確認するためのサービス発見やロードバランサである。

結局、アプリケーションがデプロイされると、第3のツールは開発者がどのようにサービス指向アプリケーションが振る舞い、問題が起きた場所や理由を探し出すのを助けるかを理解するのを手助けする。マイクロサービスの初期に遡ると、開発者はモノリシックなアプリケーションを持つことに慣れていた頃の多くの視野を失った。突然、もはやログファイルをgrepしたり、rootが引き起こしたことを発見するだけではなくなった: 今では、答えは数百のノード上のログファイルを分解され、数千の他のリクエストに綴じ込まれた。分散アプリケーションの挙動が本当に理解されたのは、マルチプロセスのトレーシングの出現、集約クリティカルパスの解析、そして高度なフォルトインジェクションだけだった。

これらのツールの多くは2016年時点で存在していたが、エコシステムはまだ開花していたなかった。幾つかの標準はあったが、新しいツールは意味のある投資が要求され、既存のツールは一緒にはうまく動作しなかった。

新しいアプローチ

ある程度このツールキットが理由で、サービスは日々、開発者ごとに考え方がある。しかし、ソフトウェアを作る中で、開発者がサービスについて初めて考え始めた時に、真の変革は起きた。テスト駆動型開発と同じように開発者はプログラムを書く前からテストすることを考え始めたことを意味した。サービス駆動型開発は、サービス依存性、パフォーマンス・インストゥルメンツ、RPCコンテキストが最初の関心事になった(そして、単に問題がその後に取り繕われないだけでなく)。

全体として、サービス(マイクロかそうでもないものでも)は望ましいことである。(我々はもはやマイクロサービスと呼ぶ必要ななく、思い返せば、重要なのはサービスのサイズでは決してなかった: それはつながりであって、それらの間の結び付きだ)。サービスは機能の周りにソフトウェア開発の話し合いを再度中心にし、開発者がより速く作業をすること、ユーザに価値を届けるという真に重要なことを実行するためにはより自由であることを可能にした。

Hacker News