マイクロサービスの人間的側面

マクロサービスアーキテクチャは、純粋に技術的なソリューションではなく、チームのコミュニケーションにとってのゲームチェンジャーだ。チーム間に安定した直接的なコミュニケーションチャンネルがない場合、彼らが作るソフトウェアはひどいものになるだろう。マイクロサービス実装を成功させるのに不可欠な5つの重要な特性は、ゼロコンフィグレーション、オートディスカバリ、高い冗長性、自己修復、フォールトトレランスだ。

Codemotion Berlin 2018で、unu GmbHでソフトウェアエンジニアリングの責任者Armağan Amcalar氏は、マイクロサービスの人間的側面について語った。InfoQではこのカンファレンスを、Q&A、サマリー、記事で紹介する。

今日の分散コンピューティングとマイクロサービスの世界では、多数の可動部品を制御し続けるために、クリーンなソフトウェアアーキテクチャが不可欠だ。エコシステム全体を理路整然と理解することでこれを最もうまく達成することができ、ソフトウェアアーキテクチャがその鍵である、とAmcalar氏は主張する。

マイクロサービスアーキテクチャは純粋に技術的なソリューションというより、チームのコミュニケーション問題のためのソリューションだ、と彼は言う。コンウェイの法則は組織のコミュニケーション構造を重視し、これらの構造を設計するシステムの構造に関連付けている。マイクロサービスもまたソフトウェアの各部のコミュニケーションパターンだ、とAmcalar氏は述べる。分離したチームで構成される企業は、分離したサービスを利用するアーキテクチャを使う必要がある。

自分たちがマイクロサービスを採用したい理由がわかっていれば、チームは最善を尽くすと彼はいう。きめ細かなスケーリングといったメリットはあるが、それは主に独立して動作する部分を調整するためだ。結局のところ、これはチームが求める仕事のやり方に多くを由来しており、技術的観点はそれほどではないという。ソフトウェアを構築する最も簡単あるいは効果的な方法だという理由で、マイクロサービスを選ぶ人はいない。彼らは心理的な理由からマイクロサービスを選んでいるのだ、と彼は言う。この事実を早くから受け入れているチームは、マイクロサービスで成功する可能性が高い。彼らはしかるべき時にどこでどのようにピボットするかわかるだろう。

InfoQでは、マイクロサービスの人間的側面についてAmcalar氏にインタビューした。

InfoQ: なぜソフトウェアアーキテクチャが必要なのですか？

Armağan Amcalar: コードを書くことは通常、単にコンピュータにすべきことを教えるアクティビティだと見なされています。でも、もし実際にそうだとしたら、私たちはみな、ずっと1と0をタイプすることになるでしょう — なぜなら、それがコンピュータにとって理解しやすいためです。しかし、私たちはもっと高レベルの言語でソフトウェアを書いています。理由はとても単純です — 他の人が使って理解できるようにコードを書くためです。同じように、ソフトウェアアーキテクチャもその延長です。ソフトウェアアーキテクチャは基本的に、組み立てて使用しようとする構造の青写真です。構築したいもの、構築したい方法についてしっかりした計画があると、非常に効果が上がります。したがって、クリーンなソフトウェアアーキテクチャは曖昧さを排除し、取り組みに対する共通理解を生み出します。

InfoQ: マイクロサービスの特性とは何ですか？ なぜそれが重要なのですか？

Amcalar: マイクロサービスはよく、ユーザーリクエストに応じて協働するクラウド規模のサービスだと説明されます。私はマイクロサービスの5つの重要な特性について定義しました。他にもたくさんありますが、これらはマイクロサービス実装が成功するために不可欠なものです。

1. ゼロコンフィグレーション: 適度なサイズのマイクロサービスアプリケーションは、クラウド環境で動作する約100種類のマイクロサービスを含むことになるでしょう。これらはオーケストレーションプラットフォームで結合され、実際にどのサービスがどのマシンで動いているのかは、誰も知りません。このハードウェア抽象化を手に入れてスケールさせるためには、サービスとサービス間の通信はゼロコンフィグでなくてはなりません。あなたはサービスのIPアドレス、ホスト名、ポートをトラックすることはできず、サービス間でその情報を交換することで、システムに参加することができます。サービスが個別の設定に依存していると、自動化されたスケール可能なマイクロサービスアーキテクチャを実現することはできません。
2. オートディスカバリ: 成功しているマイクロサービスアプリは、再設定やシステムのリブートなしに、任意のタイミングでサービス個別のデプロイおよびスケーリングができます。これは、サービスが相互に発見して通信を開始するメカニズムが必要だということを意味します。サービスのオートディスカバリによって、新しいサービスは既存のサービスを自動的に発見して通信します。既存のサービスはネットワーク内の新しいサービスを自動的に発見します。
3. 高い冗長性: マイクロサービスアプリケーションは必要に応じて動的なスケールアップまたはスケールダウンができます。ゼロコンフィグレーションとオートディスカバリを使えば、各サービスのコピーを複数動かして冗長性を高めるのは比較的簡単です。これにより、システムは個々のサービスのエラーやクラッシュに耐えられるだけでなく、同じサービスの複数のコピー間でロードバランシングを行うことができます。成功しているマイクロサービス実装には、各サービスの冗長なコピーがあります。
4. 自己修復: マイクロサービスアプリケーションは復元力のあるサービスのネットワークです。あるサービスがダウンしても、オーケストレーションプラットフォームは手作業による介入なしに、エラーしたサービスを自動的に再生成できなくてはなりません。この方法では、特定のサービスのコピーが少なくともいくつかあるため、一部ユーザーには操作に失敗するかもしれませんが、全てが失敗することはありません。
5. フォールトトレランス: 成功しているマイクロサービスアーキテクチャのもう一つの側面は、フォールトトレランスです。同一マイクロサービスの全インスタンスがいつダウンしても、少なくともそのサービスに依存しないシステムの部分は引き続き運用されなくてはなりません。また、同一マイクロサービスの全コピーが動かなくなっても、それらと通信する必要のあるサービスはリクエストを保持して、自己修復システムが起動するまで自動的に失敗してはいけません。自己修復を備えている場合、別のもっと大きな問題がない限り、障害のあるサービスは数秒のうちにオンラインに復帰することが期待されます。したがって、ユーザーは遅延があるものの、依然として適切な応答を受け取ることができます。

InfoQ: マイクロサービスアーキテクチャはチームのコミュニケーションと同じくらい堅牢で効果的だとおっしゃっていましたが、詳しく説明してもらえますか？

Amcalar: マイクロサービスアーキテクチャの最も重要な側面の一つは、障害の設計についてです。アプリケーションの特定の機能に障害があっても、他の部分は引き続き動作します。重要なサービスをスケールしたい時は、必要なものだけをスケールします。単一機能のために複数のマイクロサービスを協働させる必要がある時、意味のある性能を提供するために、特にお互いに離れているサービス間の往復の通信を最小化しようとします。

これらはすべて、異なるチーム間のコミュニケーションにも当てはまります。異なるチームが異なるマイクロサービスに責任を持っていて、それらチームの間に安定した直接的なチャンネルがない場合、彼らが作るソフトウェアはすぐにひどいものになるでしょう。

InfoQ: 開発者はコミュニケーションを望まないとおっしゃっていましたが、詳しく説明してもらえますか？

Amcalar: 特に私たちの世代の開発者は、取り組みが個人主義的になりがちです。チームワークはもちろん重要ですが、開発者は明確な受け入れ基準を持つ明確なアサインを求めています。チームは自主性とオーナーシップを求めています。彼らは他人の決定に縛られることを望んでおらず、自分自身および他人に対する決定を正当化しなくてはならないことを望んでいません。私たちの個人主義のカルチャーには、こうした不幸な副作用があります。開発者はコントロールすることを望んでおり、たいていは、他の開発者あるいは他の部門の同僚とコミュニケーションする必要がない仕事を好んでいます。

InfoQ: ジェネレーションYは世界をどのように見ていますか？ そのことはチームへの参加の仕方にどんな影響を与えていますか？

Amcalar: ジェネレーションYは、非常に有名な特徴の一つにちなんでうまく名付けられています。彼らはあらゆることに疑問を持つのです。彼らには独自の論理、理性、感情的フィルターがあり、集めた情報を全てフィルタリングします。彼らは他人を信頼しますが、他人の決定を信頼することはめったにありません。彼らは自分がしていることを完全にコントロールすることを望み、特定の事項についてオーナーシップを明確にすることを望みます。これはまた自己達成感の上昇をもたらします。ジェネレーションYは人生における意味を探し求めています。仕事は人生の大部分を占めているので、彼らはあらゆることにチャレンジすることで、そこから最高のものを作ろうとし、その周りにある全てが期待通りになるようにします。このことは、全体像を構成するために協業する、より個人主義的なチームとより独立した部品につながります。

InfoQ: マイクロサービスとDevOpsにはどんな関係がありますか？

Amcalar: マイクロサービスが真のメリットを得るには、多くの自動化が必要になります。私が前に示したマイクロサービスの重要な特性は全て、自動化に依存しています。何百ものサービスを設定、デプロイ、監視、スケール、保守するのは、人間には不可能だからです。DevOpsは自動化のカルチャーです。したがって、適切なDevOpsカルチャーがないと、マイクロサービス実装は始まりません。DevOps、自動化、infrastructure-as-code、オーケストレーションに対するそのアプローチのベストプラクティスが、マイクロサービスアーキテクチャを可能にします。適切なDevOpsプラクティスを使っていれば、マイクロサービスアーキテクチャを実装する必要はなく、モノリスや他のサービス指向アーキテクチャでも非常にうまくいく可能性があります。しかし、DevOpsプラクティスなしには、マイクロサービスで成功することはできません。