Kubernetesはプラットフォームではなく、基盤に過ぎない

原文(投稿日：2021/03/19)へのリンク

私はこれまで、印象的なKubernetesに関するツールやオートメーション、そのテクノロジを使用するさまざまな方法について、多くの記事を読み、プレゼンテーションを見てきましたが、関係するチーム名以外に、それら組織の背景が公開されたことはほとんどありませんでした。 

テクノロジの採用に関して、特にKubernetesについては、誰がそれを希望したのか、誰が必要としたのか、誰が、どのような方法で導入したのか、といったことが分からなければ、本当の意味でその成否を判断することはできません。この新たなサービスをチームがどのように受け入れたのか、あるいは受け入れなかったのか、知っておく必要があります。

Mattew Skeltonと私が共同執筆した"Team Topologies"では、チームの基本的なタイプ、期待される行動と目的、そして、おそらくはもっと重要であろう、チーム間の交流について取り上げています。テクノロジ導入の原動力になるものだから、というのがその理由です。それを考慮に入れなければ、誰も必要としない、あるいはユースケースの明確でないテクノロジやサービスを構築する、というトラップに陥る可能性があります。

チームの認知的負荷(cognitive load)はプラットフォームの成功に直接影響しますし、チームの交流パターンはプロダクトチームの不必要な負担の軽減に役立ちます。今回は、プラットフォームが認知的負荷をいかに低減するものかを確認した上で、チーム中心のアプローチによるKubernetes導入の方法について考えてみたいと思います。

Kubernetesはプラットフォームか？

2019年、AirbnbのインフラストラクチャエンジニアであるMelanie Cebula氏が、Qconで素晴らしい講演をしました。私はInfoQのDevOps担当リードエディタとしてそれを記事にしたのですが、オンライン公開した最初の1週間だけで23,000ページビュー以上を記録したのです。自分の記事がこれほどバズったのは初めてだったので、なぜそれほどの読者を引き付けたのか、理解したいと思いました。Airbnbが有名企業であることや、Kubernetesがブームであることも理由ですが、最も大きな要因は、多くのエンジニアにとって、この記事がKubernetesの大規模導入を簡潔に紹介したものであることだ、と私は考えています。

ここでのポイントは、Kubernetesの導入、APIによる開発手法への変更、効果的な利用に必要なアーティファクトの作成といったものを、難しいと感じている開発者やエンジニアがたくさんいる、ということです。 

つまり、"プラットフォーム"という用語が、さまざまな意味で負担になっているのです。マイクロサービスの煩雑な運用を支援するという意味から言えば、Kubernetesはプラットフォームです。サービスのデプロイや実行を、適切な方法で抽象化してくれます。それは間違いなく素晴らしいのですが、それだけではありません。ホストのサイズをどうするか、クラスタをいつどうやって生成し廃棄するのか、Kubernetesの新バージョンへのアップデートはどうするのか、その影響は誰が受けるのか、を考えておかなくてはなりません。個々の環境やアプリケーションを分離する方法はどうするのか — ネームスペースか、クラスタか、あるいは他の方法なのか、ということも決めておく必要があります。Kubernetesを使って仕事をする人ならば誰でも、このリストに1行書き足すことがあるはずです。例えば、セキュリティを懸念している人もいるでしょう。Kubernetesをプラットフォームとして使う前には、やっておかなくてはならないことがたくさんあるのです。

そこで問題になるのは、組織内での役割の境界が往々にして不明確であることです。プロバイダはどこか？これらすべての実施に責任を負うオーナは誰か？コンシューマは誰か？プラットフォームを利用するのはどのチームか？境界が曖昧であれば、誰が何の責任を負うのか、意思決定が他のチームにどのような影響を与えるのか、といったことを理解するのが難しくなります。

Evan Bottcher氏はディジタルプラットフォームを、"セルフサービスAPI、ツール、サービスのみならず、知識とサポート、さらには説得力のある社内プロダクトとしてアレンジされたすべてのものの基盤"である、と定義しています。この中で、セルフサービルツールとAPIの重要性は誰もが知っているでしょう。これらは多くのチームにとって、独立性を高め、自律的な作業を可能にする上で非常に重要なものなのだからです。ですが私は、氏が"知識とサポート"に言及したことに注目してほしいと思います。これは、プロダクトチームによるプラットフォームの理解と導入支援に重点を置くと同時に、問題が発生した場合にはサポートを提供してくれる、プラットフォーム運用チームの必要性を暗示しているのです。

もうひとつ重要なのは、プラットフォームは"説得力のある社内プロダクト"ではあって、共有サービスをすべての人たちに課すための強制的なプラットフォームではない、という点です。ひとつの業界として、私たちはこのようなことを長く続けているのですが、簡単なことではありません。万能の解決策であるはずのプラットフォームが、利用を強いられるチームにとっては、提供されるメリットよりも、付随して生じる苦労の方が多いものであることが少なくないのです。そして、万能の解決策(銀の弾丸)など存在しないのです。 

プラットフォームはプロダクトとして考える必要があります。社内チーム用であっても、プロダクトであることに違いはありません。実際にこれが何を意味するのかは、これから見ていきましょう。

重要なポイントは、Kubernetesそれ自体はプラットフォームではない、という点です。基盤(foundation)なのです。提供する機能は確かに優秀です — 自動スケール、自己回復、サービスディスカバリ、など ー が、優れたプロダクトは、単なる機能セット以上のものです。導入の容易さ、信頼性、プラットフォームのサポートなども考えなくてはなりません。 

Bottcher氏の言うように、"優れたプラットフォームは最も楽な道を作り出せなくてはならない"のです。基本的にプラットフォームでは、正しいことを行うのが最も楽なことでなくてはなりません。そう考えると、Kubernetesの行っていることがすべて正しいとは言えないのです。何が正しいのかは、チームの状況や、チームがプラットフォームに求めるもの、最も必要としているもの、支援を必要としているものなどによって違います。

プラットフォームの難しさのひとつは、カスタマの新旧によって内部チームのニーズが変化することにあります。プラットフォームを使用するチームは、時間が経つにつれて、より具体的な要求や要件を持つようになります。それと同時に、プラットフォームは、新たに使用するチームやエンジニアにとっても理解しやすく、使いやすいものでなければなりません。ニーズとテクノロジのエコシステムは、常に進化しているのです。

図1: Kubernetesの導入時には、チームの孤立が発生することを回避する

チームの認知的負荷

Kubernetesの採用に伴う変化は小さくありません。象が部屋に飛び込んできたようなものです。得られるメリットよりも生じる苦痛の方が大きくならない方法で、このテクノロジを採用する必要があります。図1のようにグループが孤立する、DevOpsムーブメント以前の状況に戻ってしまうのは、私たちが望む結果ではありません。運用チームではなくKubernetesチームである、という違いはあるにしても、ひとつのグループが他グループとは独立した形で意思決定する分離型のアプローチにしてしまうと、これと同じような問題に直面することになります。

コンシューマへの影響を考えずにプラットフォームを決定してしまえば、認知的負荷、すなわちプラットフォームを理解し、使用するために費やす必要のある労力という形で、彼らの苦痛を増大させることになるのです。

John Sweller氏は認知的負荷について、"ワーキングメモリで使用される精神的労力の総量"であるという定義をしています。認知的負荷はさらに、内因性(intrinsic)負荷、外因性(extraneous)負荷、関連(germane)負荷という３タイプに分けることができます。 

これら3つの認知的負荷は、それぞれをソフトウェアデリバリにマップすることができます。すなわち、内因性負荷は自分の仕事をするために必要なスキルであり、外因性負荷は価値を提供するために必要な仕組みやもの、関連負荷はドメインのフォーカスです。

内因性の認知的負荷とは、例えばJava開発者であれば、Javaでクラスを書く方法の知識です。方法を知らなければ、努力が必要です。Googleで検索するなり、思い出すなり、しなくてはなりません。しかし、内因性認知的負荷を最小化する方法は分かっています。昔ながらのトレーニングやペアプログラミング、メンタリング、コードレビューなど、スキル向上に有益なあらゆるテクニックが使用できるのです。

外因性認知的負荷には、カスタマや運用環境に対して提供する必要のある、すべてのタスクが含まれています。このアプリケーションをデプロイする方法、ステージング環境にアクセスする方法、テストデータをクリーンアップする方法などは、問題の解決に直接的な関連を持ってはいませんが、覚えておかなくてはならないことです。特にチームトポロジとプラットフォームチームは、外因性認知的負荷を最小限に抑えることが可能です。本記事の以降の部分では、これについて説明したいと思います。

最後の関連認知的負荷とは、ビジネスドメインや問題空間に関する知識です。例えば、プライベートバンキングを扱っているならば、銀行振込の仕組みについて知っておかなくてはなりません。外因性認知的負荷を最小限にする必要があるのは、関連認知的負荷に集中するために、可能な限りのメモリを開放しておくためなのです。

Jo Pearce氏の記事"Hacking Your Head"とプレゼンテーションでは、これについて深く掘り下げています。

ここでの一般的な原則は、プラットフォームの選択がチームの認知的負荷に与える影響に留意する、ということです。

ケーススタディ

先程、AirbnbのエンジニアであるMelanie Cebula氏のQconでの講演を紹介しましたので、同社が開発チームの認知的負荷をどうやって軽減したのかを見ていきましょう。 

"私の毎日で至福の時は、1行のコード変更をデプロイするために10個のYAMLファイルを修正する時間です"、と言う人はいないでしょう。Kubernetesを導入する過程で、Airbnbのチームは、これと同じような苦痛を感じていたのです。この認知的負担を低減するため、彼らは、kube-genというシンプルなコマンドラインツールを開発しました。このツールは、アプリケーションチームやサービスチームに対して、自分たちのプロジェクトやサービスに特有のコンフィギュレーションセットや詳細だけを意識すればよいようにしてくれます。チームに必要なのは、自分たちのアプリケーションと密接な関係にあるファイルやボリュームの設定をすることだけです。後はkube-genツールが、それぞれの環境(運用環境、カナリア環境、開発環境など)に適した、定型的なコンフィギュレーションを生成してくれます。これによって開発チームは、自分たちに密接に関わる作業に、容易に集中することができるようになるのです。 

図2: kube-genの使用によって簡略化されたAirbnbのKubernetesエコシステム

Airbnbが行ったように、プラットフォームが提供するサービスのバウンダリを明確化して抽象化することによって、各サービスチームの認知的負荷を軽減することが一般的に望まれています。

前述の"Team Topologies"では、図3に示すような4タイプのチームについて説明しています。ストリーム構成チーム(stream aligned team)は、エンドカスタマに価値を提供する、ビジネス価値を実現する上での心臓部です。他の3タイプのチームはそのサポートと、認知的負荷の軽減を支援します。プラットフォームチーム(platform team)は、デプロイメントや監視、CI/CDなどに使用する低レベルのサービスや、その他ライフサイクルをサポートするサービスの詳細を隠蔽します。

図3: 4タイプのチーム

ストリーム構成チームは、組織によってはプロダクトチーム、DevOpsチーム、ビルド・アンド・ランチームなどとも呼ばれています — いずれも提供するサービスに対して、エンドツーエンドのオーナシップを持つチームです。ランタイムのオーナシップを持ち、監視や実際に使用するユーザからのフィードバックを取得して、サービスやアプリケーションの次のイテレーションで改善することができます。これを"ストリーム構成チーム"と呼ぶのには、2つの理由があります。第1に、"プロダクト"の持つ意味が多過ぎることです。システムがますます複雑になるにつれて、スタンドアロンプロダクトの定義は正確さを失っています。第2に、単なるビジネス価値のストリームを越えた、違うタイプのストリームを認めたいと思うからです — それはコンプライアンスかも知れませんし、特別なユーザのペルソナかも知れません。あるいは、チームをその提供する価値に見合ったものにする上で意味のある、何か別のものかも知れないのです。

もうひとつのケーススタディはuSwitchに関するものです。同社は、英国のユーザを対象に、ユーティリティプロバイダやホームサービスを比較して、それらを切り替えるための支援をする企業です。

2年前、同社でエンジニアリングの責任者を務めるPaul Ingles氏が書いた"Convergence to Kubernetes"には、Kubernetesの採用と、それがチームや仕事に与えた功罪、有意義な分析のためのデータがまとめられています。図4はその記事からの引用で、uSwitchにおいて、さまざまなチームの低レベルAWSサービスコールをすべて測定したものです。 

uSwitchがスタートした頃は、すべてのチームが自身のサービスに責任を持ち、可能な限り自律的に活動していました。AWSアカウントやセキュリティグループ、ネットワークなどの生成はチーム自身の責任でした。やがて同社では、これらサービスの呼び出し数の増加に伴って、チームの新機能やビジネスバリューの提供が遅くなっていることに気付いたのです。

図4: 時間経過に伴う低レベルAWSサービスの使用数

Kubernetesの採用を通じてuSwitchが望んだのは、単にテクノロジの導入だけではなく、組織構造の変革や、インフラストラクチャプラットフォームチームの導入といったものも含んでいました。これによって、さまざまなAWSサービスを低いレベルから理解しなければならないという、チームが抱える認知的負荷の増加に対処しようとしたのです。 

これは素晴らしいアイデアでした。プラットフォームを導入すると、AWSに直接向かうトラフィックは低下しました。図5に示した呼び出し数のカーブは、アプリケーションチームの認知的負荷をそのまま表現しています。このコンセプトは、セルフサービス機能によってストリーム構成チームがより自律的に作業できるようにすると同時に、外因性認知的負荷を低減するという、プラットフォームチームの目標とも合致しています。"さあ、共有サービスをすべてプラットフォームに用意しましたよ"と言うのとは、概念的にまったく異なる出発点なのです。 

Ingles氏はまた、セルフサービス的なインフラストラクチャプラットフォームを提供することによって、チームの自律性や最小限のコーディネーションで活動するチームという、それまで自分たちの持っていた原則を維持したかった、とも書いています。

図5: Kubernetesベースのプラットフォームの導入により、低レベルAWSサービスコールの数は低減した

プラットフォームをプロダクトとして扱う

次に、プラットフォームをプロダクトとして扱うことについて話ましょう — 社内プロダクトであっても、プロダクトであることに変わりはありません。これはつまり、信頼性や目的との一致性、使用する時の開発者エクスペリエンス(DevEx)を考慮しなければならない、ということです。

まず最初に、プラットフォームが信頼に値するためにはオンコールサポートが必要です。プラットフォームは今、実運用の過程にあるからです。例えば、プラットフォームの監視サービスに障害が発生したり、ログのストレージ領域が枯渇したりすれば、顧客対応チームは窮地に陥ることになります。サポートを提供し、何が起きているのかを報告して、修正のための予想時間を見積もる誰かが必要なのです。また、プラットフォームの状態を理解しやすいものにすることや、プラットフォームチームとストリームチームの間にクリアなコミュニケーションチャネルを確立して、コミュニケーションにおける認知的負荷を軽減することも必要です。さらに、計画的なダウンタイムに関しては、影響を受ける可能性のあるチームとのコーディネーションが必要になります。

第2に、目的に合ったプラットフォームを用意するためには、プロトタイピングのようなテクニックを使ったり、社内ユーザから定期的にフィードバックを収集したりすることも必要です。より早く、より高品質なデリバリのためには、アジャイルやペアプログラミング、TDDといった反復的なプラクティスを使用します。ここで重要なのは、有用と思われるすべてのサービスを開発しようとするのではなく、品質と可用性の高い少数のサービスを持つことを重視すべきだ、という点です。チームが本当に求めているものに集中し、それを高品質で提供する必要があります。これには非常に優れたプロダクト管理、優先順位の理解、明確だが柔軟なロードマップ、といったものが必要です。

さらに、開発チームとプラットフォームチームが同じ言葉で話すことで、エクスペリエンスやユーザビリティを最大化することが可能になります。プラットフォームはサービスを明確な方法で提供する必要があります。時には妥協も必要でしょう。もし開発チームがYAMLに不慣れならば、すべての開発チームにYAMLをトレーニングすれば、少ないコストと労力で長期的なメリットが得られる、と考えるかも知れません。しかし、このよう判断が必ずしも自明であるとは限りません。開発チームや利用チームへの影響を考えずに、このような決断を下すべきではないのです。今日のチームにとって適切なレベルの抽象化を提供する必要がありますが、将来的には状況が変化するかも知れません。もっとよい、あるいはより高い抽象化レベルを採用する方法もあるでしょう。ですが、現時点での成熟度やチームのエンジニアリングプラクティスにとって、それが適切であるかどうかは見極めておかなくてはなりません。

Kubernetesの支援によって、uSwitchでは、AWSでそれまで使用していた低レベルのサービス抽象化に代えて、サービスやデプロイメント、イングレス(ingress)を対象とした、よりアプリケーション中心の抽象化を確立することができただけでなく、もうひとつの重要な原則であるコーディネーションの最小化にも役立ちました。 

Ingles氏と、当時uSwitchのインフラストラクチャのリーダであったTom Booth氏から、彼らが何を、どのように行ったのかを聞きました。

プラットフォームチームはサービスチームを支援するために、動的なデータベース認証やマルチクラスタロードバランシングを提供した他、サービスチームの顧客応対サービスからの警告の取得、サービスレベル目標(SLO)の定義、さらにはそれらすべての可視化についても、サービスチームが容易にできるようにしました。プラットフォームによって、SLOをダッシュボードで簡単に構成し、監視することが可能になりました — ある指標が閾値を下回ると、図6に示したように、通知がSlackに送出される仕組みです。

図6: Slackを使用したuSwitchのSLO閾値通知の例

これら新たなプラクティスを、チームは容易に受け入れることができました。uSwitchのチームはYAMLに慣れていたので、これらのサービスを設定して利用するのは簡単でした。 

技術面を越えた成果

uSwitchの取り組みには、技術的な成果以外にも見るべきものがあります。同社はこのインフラストラクチャの導入を、2018年に、ごく少数のサービスで始めました。最初のユーザとしては、集中的なログ機能やメトリクス、あるいは自動スケールの欠如で苦労をしていた、ひとつのチームを選びました。これらの面を中心としてサービスを拡大することが成功への第一歩になる、と彼らが考えていたからです。

その後、プラットフォームチームは、パフォーマンスやレイテンシや信頼性の向上を強調するために、社内において他のサンプルとなるようなKubernetesプラットフォーム用の独自SLAとSLOの定義に着手しました。他のチームは、観察と十分な情報に基づいて、プラットフォームサービス採用の可否を判断することができました。ここで強調しておきたいのは、それが義務ではなく、あくまでもオプションである、という点です。 

Booth氏から聞いたところでは、uSwitchでは、AWSを直接通過するトラフィックに対して、Kubernetesプラットフォームを経由するトラフィックが増加したことによって、プラットフォームの採用がどの程度進んでいるかを把握したということです。その後、チームは、セキュリティやGDPRデータプライバシ、警告の処理、SLOといった、機能横断的な重要問題のいくつかに取り組みました。

エンジニアリング部分と利益創出の両面で抜きん出ていた、あるチームは、すでにKubernetesプラットフォームが提供するものをすべて使いこなしていました。このチームは最初、プラットフォームの採用に特別なモチベーションを持っていた訳ではありませんでした — 従来と同じ機能を信頼性やパフォーマンスなどのレベルが向上した形で提供する、という確信を彼らが持つまでは。これらインフラストラクチャの提供するものをすべて自分たちで処理するというのは、もはや考えられなくなっていました。Kubernetesプラットフォームにスイッチしたことによって、このチームは、サービスのビジネス面により力を傾けることができるようになったのです。組織内で最も進んだエンジニアリングチームの採用を得たことが、プラットフォームチームにとって"究極の"称賛になりました。

4つの重要なメトリクス

図7: 4つの重要なメトリクス(書籍"Accelerate"より)

メトリクスは極めて有用です。プラットフォームはプロダクトと見なすべきである、という考え方から、プロダクトメトリクスの参照が可能になります — 図7のカテゴリは、Nicole Forsgren、Jez Humble、Gene Kim各氏の著書である"Accelerate"に紹介されているものです。同書の中では、ハイパフォーマンスなチームはリードタイムやデプロイメント頻度、MTTR、変更時障害率(change failure rate)といった重要なメトリクスをうまく利用している、とされています。自身のプラットフォームサービスのデリバリやオペレーションのために、これを使うことができます。

Accelerateのメトリクス以外では、顧客満足度を重要な測定基準として利用することができます。ユーザのためにプロダクトを開発する場合には、ユーザの仕事を支援し、ユーザがそれでハッピーになり、他の人たちに勧めてくれるようなものにしたい、と思うでしょう。分かりやすい例がTwilloにあります。同社のプラットフォームチームは、四半期毎あるいはその位の頻度で、エンジニアリングチームに対して、自分たちのプラットフォームがサービスの構築、デリバリ、実行にどの程度役に立っているか、使用する上でどの程度魅力的かなど、いくつかの質問(図8)をしています。

図8: Twillioのプラットフォームチームがエンジニアリングチームに送る調査票

このような簡単なアンケートを使えば、時間の経過に伴う顧客満足度の変化やトレンドを把握することが可能になります。技術的サービスとしての一般的な満足度レベルだけではなく、プラットフォームチームによるサポートも評価できるのです。例えば、プラットフォームチームが一時的に忙しく、フィードバックに十分な対応ができなかったことが理由で、不満の声が上がるかも知れません。テクノロジだけの問題ではない、チーム間の交流(interaction)が必要なのです。

もうひとつの計測すべき重要な領域は、プラットフォームの採用や関わりに関する部分です。最終的にプラットフォームが成功するためには、それが採用されなくてはなりません。サービスを提供することが目的なのです。最も基本的なレベルでは、組織内でプラットフォームを使用しているチームと使用していないチームの数を対比することが考えられます。プラットフォームサービス単位での採用数や、特定のサービス機能の利用を見る方法もあるでしょう。それらの情報は、サービスないし機能の成功を判断する材料になります。簡単に導入できると考えていたサービスの利用が思わしくなければ、原因となった可能性のあるものを探すことができます。

さらに、uSwitchが行っていたように、プラットフォーム自体の信頼性を評価することも、同じように重要です。uSwitchではプラットフォームに独自のSLOを設定して、すべてのチームに公開していました。このような情報を提供することが極めて重要なのです。

図9: プロダクトとしてのプラットフォームにおいて有用なメトリクス

図9はメトリクスのカテゴリの例を示しています。企業にはそれぞれの状況に応じた特有のメトリクスがあるかも知れませんが、私たちが見るべきタイプやカテゴリには、多かれ少なかれ共通したものがあるはずです。

チームの交流

プラットフォームチームの成功は、ストリーム構成チームの成功に他なりません。2つのチームは一心同体です。サポートチームとはそういうものなのです。チームの交流が重要なのは、成功がもはやテクノロジを利用できるようになることだけではなく、そのテクノロジのユーザが期待する速度や品質、運用性といったメリットを獲得するための支援にあるからです。

図10: Airbnbのプラットフォームチームが提供するKubernetesアーキテクチャ基盤の抽象化

Airbnbには事実上のプラットフォームチーム(社内ではインフラストラクチャチームと呼ばれています)が存在して、図10に示すように、基盤にあるKubernetesプラットフォームの詳細の多くを抽象化しています。これにより、開発チームに対するプラットフォームの境界が明確になると同時に、Kubernetesの使い方を説明したり、動作原理を理解するために公式資料を読んだりすることに比べて、認知的負荷がはるかに小さなものになっているのです。これは非常に多くの労力を必要とする、大変な作業です。このプラットフォームチームのアプローチでは、チームの必要に合わせて焦点を絞り込んだサービスを提供することによって、認知的負荷の低減に成功しています。

これを実現するには、チーム間の適切な行動と交流が必要です。新たにプラットフォームサービスを立ち上げるにせよ、既存のものを変更するにせよ、プラットフォームチームと、新たなサービスを使用する最初のストリーム構成チームとの間には、強いコラボレーションが必要となります。ディスカバリ期間(discovery period)の最初の段階から、プラットフォームチームには、ストリーム構成チームのニーズを理解し、そのニーズを満たす最もシンプルなソリューションとインターフェースを探すことが求められます。ストリーム構成チームがサービスの使用を始めたならば、プラットフォームチームは重点をサービスのサポートに移して、新たなユーザが参加するために、フォローの容易な最新のドキュメントを提供する必要があります。チーム間のコラボレーションはそれほど必要ではなくなり、プラットフォームチームは優れたサービスの提供に注力します。このような交流モードが、X・アズ・ア・サービスと呼ばれるものです。

ただしこれは、プラットフォームがすべてを隠蔽するので、開発チームには背景で何が行われているのか分からない、という意味ではない点に注意してください。それが問題ではないのです。プラットフォームがKubernetesベースであることは皆が知っています。チームがフィードバックを返したり、新たなツールやメソッドを提案したりするのを妨げるべきではありません。そのような関与や、ストリーム構成チームとプラットフォームチーム間の議論は、実際には促進すべきものなのです。

例えば、Kubernetesのトラブルシューティングサービスは、非常に複雑なものになる場合があります。図11は、Kubernetes内においてデプロイメントを診断するフローを、上位半分のみ示したものです。問題が発生するたびにエンジニアリングチームがこのような作業を行うというのは、私たちの望む姿ではありません。Airbnbもそうでした。

図11: Kubernetesのデプロイメントに関するトラブルシューティングフローの半分

Airbnbでは、チーム同士が密接に関係して、問題を診断するためにどのような情報が必要か、どのようなタイプの問題が定常的に発生しているか、といったことの理解を目的としたディスカバリ期間を設けました。この結果として、トラブルシューティングサービスのあるべき姿を合意することができたのです。最終的にサービスはクリアになり、すべてのストリーム構成チームによる使用に耐える安定性を得ることができました。

Airbnbではすでにプラットフォーム上で、 kube-gen と kube-deploy という２つのサービスを稼働させていました。新たなトラブルシューティングサービスのkube-diagnoseは、関連するすべてのログ、あらゆる種類のステータスチェック、その他の有用なデータを収集することにより、開発チームの作業を単純化してくれます。すべてのデータの所在やそれらを取得するためのステップを覚えていなくても、問題の潜在的原因に集中することによって、障害診断ははるかに簡単になります。

図12: Airbnbのインフラストラクチャ(プラットフォーム)チームが提供するサービス

図13: クラウドネイティブなランドスケープ

図13は、クラウドネイティブなランドスケープの広がりを表したものです。ストリーム構成チームがこれを自ら扱うというのは、望ましいことではありません。プラットフォームチームの役割のひとつに、テクノロジのライフサイクルをフォローする、というものがあります。その重要性は誰もが知るところです。現在の社内プラットフォームチームにあるカスタムコードを削減する(あるいは古く、信頼性の低いツールを取り除く)作業を支援する、リリースされたばかりのCNCFツールがあると想定しましょう。この新しいツールを、ストリーム構成チームのプラットフォームサービス利用に影響を与えないような透過的な方法で採用することができれば、発展を続ける状況に対応するという名目において、より簡単な手段を手に入れたことになります。

対照的に、プラットフォームに採用したいと考えている新たなテクノロジが、ひとつ以上のサービスインターフェースの変更を伴うものである場合には、ストリーム構成チームに相談し、彼らに必要となる作業について理解した上で、そこで実施されるトレードオフの評価をしなければなりません。マイグレーションや採用に伴う現在の労力に比較して、長期的に十分なメリットを得ることができるのでしょうか？ 

そうであれば、社内プラットフォームのアプローチを活用することで、プラットフォーム内のテクノロジの進化を可視化することが可能になります。

図14: uSwitchは、プラットフォームチームが当初は社内向けに開発した、オープンソースツールのHeimdailをオープンソースとして公開した

オープンソースソリューションを採用する場合でも同じです。例えばuSwitchは、SLOダッシュボードサービスにチャットツールのインテグレーションを提供するアプリケーションのHeimdallや、その他たくさんのツールをオープンソースとして公開しています。そのひとつであるZalandoは、クラスタのライフサイクル管理を行う、最高にクールなツールです。ここでポイントとなるのは、あるオープンソーステクノロジが自分たちの必要なものであった場合、それがプラットフォームの抽象化レベルより下に位置するものであれば、導入は比較的容易なものになる、ということです。透過的な変更でない場合には、ストリーム構成チームと協力して、影響を受けるサービスを彼らがどのように使っているかという視点から、必要な変更を見極めなくてはなりません。

チーム中心のアプローチで始める

Kubernetes採用におけるチーム中心のアプローチには、3つの重要な点があります。 

ひとつは、開発チームあるいはストリーム構成チームの認知的負荷の評価から始めることです。Kubernetesベースの現状のプラットフォームが、彼らにとってどの程度理解しやすいものであるかを判断しましょう。彼らが知る必要のあるのは、どのような抽象概念か？それは簡単か、あるいは苦労を伴うものなのか？必ずしも科学的ではありませんが、このような質問をすることによって、彼らが直面し、支援を必要としている問題に関する感覚を掴むことが可能になります。Airbnbのケーススタディが重要なのは、Kubernetes採用におけるツールベースのアプローチにおいて、適切なサポートやDevEx、あるいは真のニーズを理解するためのコラボレーションのないまま、ユーザにまったく新しいプラットフォームを使うことを求めるのならば、それは困難と懸念を伴うものになる、ということを明確にしているからです。

次に、プラットフォームを明確にしなくてはなりません。多くの場合これは簡単ですが、常に行われるとは限りません。プラットフォームで用意するすべてのサービスとそれぞれの責任者に加えて、オンコールサポートの責務、通信メカニズムなど、これまでに述べたディジタルプラットフォームのすべての面を正確にリストアップしてください。これらがすべて、明確である必要があります。まずは現実のKubernetesプラットフォームと理想的なディジタルプラットフォームとの間のギャップを確認し、その上で、それらに対処していくのです。

最後に、チームの交流を明確にすることです。コラボレーションすべき時はいつなのか、独立してサービスを利用できるようになるべき時はいつなのか、ということを意識してください。新たなサービスをどのように開発するのか、それには誰が、どれだけの期間、関与する必要があるのかを判断しましょう。単に"コラボレーションする"と言って、交流期間を制限しないでおくべきではありません。実際にサービスの開発に着手する前に、新サービスに求めるものは何か、サービスインターフェースはどうあるべきかの理解に2週間というように、コラボレーションの期間を決めておきましょう。必要なディスカバリを最初に行ったならば、機能や信頼性に重点を移しましょう。ある時点において、サービスが"一般供用(generally available)"できるようになれば、交流は"X・アズ・ア・サービス"へと進展します。

Zalando、Twilio、Adidas、Mercedesなど、企業の実例には優秀なプラットフォームがたくさんあります。これらの企業に共通する文脈は、テクニカルなサービスだけではなく、優れたサポート、オンコール、高品質なドキュメントで構成されるディジタルプラットフォームアプローチです。これらすべてが、プラットフォームをチームにとって使いやすいものにすると同時に、ソフトウェアのより自律的な提供と運用を促進しているのです。ここで挙げたことに関しては、TechBeaconに関する記事でもう少し深く掘り下げています。 

著者について

Manuel Pais氏は、独立系IT企業コンサルタント兼トレーナで、チーム間の交流、デリバリのプラクティス、フローの促進に注目しています。書籍"Team Topologies: Organizing Business and Technology Teams for Fast Flow"の共著者でもある氏は、企業がソフトウェアデリバリへのアプローチ、運用、戦略的アセスメントを通じたサポート、実践的ワークショップ、コーチングを再考するための支援を行っています。