「自由」がゆえに「複雑」になったクラウド／OSS時代をどう生きるか？
1940〜50年代に活躍した映画監督オーソン・ウェルズは、「制約がないことが、創造の敵になる」という言葉を残した。これは芸術において「制約は必ずしも悪ではない」ということを意味するが、ソフトウェア開発者にとっても同じではないだろうか。
町田氏は、まず現代の開発者が獲得した自由と、その結果生じた新たな課題について整理する。
現代のITシステムはとても複雑だ。オンプレミス、クラウド、OSS、SaaSといった複数の技術領域が絡み合い、その組み合わせの選択肢はレゴブロックのように増え続けている。自由度が高まったことで、スピードや柔軟性の面では大きなメリットが生まれる一方、それぞれの技術を理解し、使いこなすための認知負荷も増大するばかりだ。各領域でベストプラクティスやブループリントの整備は進んでいるものの、ベンダー固有のIAM設定や監視体制、運用ルールなど、理解しなければならない前提条件や作法は、かえって増えてしまった。
さらに、オンプレミスやマルチクラウドなど複数の環境を使い分けることが当たり前となり、環境間の差異や複雑性が増大した結果、原因の切り分けが困難なトラブルが増加している。例えば障害が発生した際、影響範囲の特定も難しくなり、対応の長期化を招いてしまう。その結果、サイロ化の進行を招くとともに、安定的な運用を維持することも難しくなっている。
このような複雑性は、開発者にも悪影響を与えている。本来、開発者のミッションは、ユーザーに対していかに早く継続的に価値を届けるかという点にあるはずだ。しかし、開発者は「何を選べばいいのか」「どう構成すればいいのか」「この選択は本当に正しいのか」という運用面での判断を常に迫られている。こうした判断の積み重ねが、開発者にとっての大きな負担になっている。
さらに深刻なのは、人材の供給が追いつかないことだ。複数の環境を横断的に見られる人材は希少化し、一部の高スキル人材にレビューや障害対応が集中。結果として、対応にかかるリードタイムが延びてしまう。しかし人材の育成と供給は一朝一夕にはいかないため、慢性的な人材不足が続く。こうした現場の疲弊は、個人の能力の問題ではなく、利用するサービスや技術が細分化・多様化した結果であり、環境の構造やアプローチの問題だと、町田氏は指摘する。
そこで町田氏が勧めるのが、こうした混沌とした状況を制御するために、一定の制約を設けることだ。
「技術的な選択肢が数多く存在するからこそ、その自由度の高さがかえって迷いを生み出し、開発者が本来の生産性を発揮する妨げになっています。そこで、環境に依存しない共通の運用作法を整備するとともに、開発者向けの推奨ルート（Golden Path）を定めることで、開発者が運用面で煩わされる負担を減らすことが必要です」（町田氏）
共通化のカギは「技術ごとの判断や検討が必要な場面をできるだけ減らすこと」
それでは、共通の運用作法を実現するには、どこから着手していけばよいのだろうか。町田氏は、共通化を考えるポイントを以下の3点に整理する。
第1に、「どのように環境を変更するか」という点だ。これは、変更手順やチェック、ロールバックの仕組みを揃えることを指す。第2に、「どのように環境を守るか」だ。環境を守る、とはポリシーによる最低基準の自動的な担保を指している。最後に、「どのように環境を保つか」。環境の作成・更新・廃棄というライフサイクルの管理をしなければいけない。
この3点を揃えていくことで、開発者がコードを書くことに集中でき、ユーザーに向けて自信を持って、より頻繁にリリースできるようになるはずだと、町田氏は伝える。
オンプレミスやクラウドなどの環境に依存しない、共通の運用作法を実現するプラットフォームとして、町田氏は「Kubernetes」と、その周辺のOSSツール群を推奨する。CNCF（Cloud Native Computing Foundation）は、Kubernetesを中心にクラウドネイティブ技術を推進する団体だ。このエコシステムには、オーケストレーションから、GitOps、可観測性、セキュリティ、ポリシーまで、幅広い領域をカバーするツールが揃っている。
中でもKubernetesは登場から10年以上が経過し技術として十分に成熟しており、オンプレミスからパブリッククラウドまで幅広い環境で動作実績を持つ。加えて拡張を前提に設計されているため、組織固有の要件にも対応できる柔軟性がある。CNCFのエコシステムを最大限活用しながら、差別化が必要な部分だけ作り込み、それ以外の部分について標準化を進めるのが良いと、町田氏は勧める。
共通のプラットフォームの上に置かれるのが、推奨ルート（Golden Path）だ。これは、プロジェクトテンプレート、標準CI/CDパイプライン、可観測性の初期セット、変更・ロールバックの基本手順など、開発からリリースまでに必要なツールと手順を一般化したものだ。推奨ルートがあれば、開発の立ち上げが速くなり、CI/CDによる自動チェックがレビューの負担を軽減し、可観測性とロールバックが担保されるので開発者の不安が減る。さらに、チームの暗黙知にとどまっていた正しい進め方が、仕組みとして組織全体で共有されるようになるなど、さまざまなメリットが生じる。
共通のプラットフォームを整備する際には、共通化する領域と、裁量に任せる領域を見極めることが重要だと、町田氏は指摘する。変更・ロールバックの仕組みやセキュリティ標準はすべての環境で共通化するべきだが、アプリケーションの設計・実装やプログラミング言語の選択といった開発寄りの領域は、チームの裁量に委ねた方がよい。開発ツールは、環境依存の制約が生じやすく、共通プラットフォームとは馴染まない面があるという。まずインフラから共通プラットフォーム化を進め、開発環境は推奨ルートとして整備していくのが望ましい。
「日々の現場で発生する、技術ごとの判断や検討が必要な場面をできるだけ減らすこと。そして、同じ目的を実現する際に、そのための手段を再利用できる範囲を広げていくことが、共通化の目的です」（町田氏）
Apache MesosからKubernetesへ受け継がれた「分散基盤をOS化する」発想
共通の運用作法を実現するために必要不可欠な3つの要素が、GitOps、ポリシー、ライフサイクル／フリート管理だ。
GitOpsは、アプリケーションのデプロイやインフラの構成変更といった変更作業を安心・安全に実行するための仕組みだ。変更の入口をGitに一元化することで、何が変更されたかの差分の可視化、いつ誰が変更したかの履歴管理、そして問題発生時の確実なロールバックが可能になる。変更ポイントが明確になることで、「このシステムは怖くて触れない」という状況が減り、安心して継続的なリリースができるようになる。
ポリシーを整備する狙いは、禁止事項を増やすのではなく、最低限守るべき基準を自動で担保することにある。権限管理やネットワーク境界の設定、ソフトウェアサプライチェーン、脆弱性の最低基準といった、毎回設計やレビューが必要になりがちな要素から整備を始めるのが有効だ。開発者にとってこれらはコーディングと直接関係しない領域であり、共通化によって本来の作業に専念できるようになる。
KubernetesなどのOSSを活用する上で、ライフサイクル管理も必要不可欠だ。OSSでは、新しいバージョンや機能のリリースが頻繁に行われ、脆弱性やバグへのタイムリーな対応が求められる。そのため、いかに更新作業を安定・安全かつ効率的に実行できるかが重要だ。
具体的には、更新前の検証や段階的な適用手順を整備し、障害の影響範囲をコントロールしながら、本番に適用し続けねばならない。そこでKubernetesクラスタの作成・更新・廃棄の流れを自動化前提で設計することがポイントになる。これを怠ると、環境が増えるにつれて差異が拡大し、アップグレードが先送りされ、限られた人材しか対応できないリスクが高まる。
このリスクを軽減する上で、一元管理への転換も重要だという。つまり、クラスタを個別に管理するのではなく、環境や目的に応じてグループ化（フリート）し、フリートごとにライフサイクルの自動化を適用していく。そうすることで、運用のスケーラビリティを確保しつつ、環境間の差異を極力なくしていくことにつながるという。
これらの設計思想の源流は、2010年代前半、TwitterやAirbnbといった新興企業がトラフィックの急増によるスケールに苦しんでいた時代に遡ると、町田氏は歴史を振り返る。その際、大規模分散処理基盤の技術としてKubernetesと並んで注目されていたのが「Apache Mesos」だ。「分散基盤をOS化する」というMesosの発想と、大規模分散環境運用の知見は、コマーシャルサポートを担ったMesosphere社からD2iQへ、そしてNutanixへと受け継がれた。
その技術は現在、Nutanix Kubernetes Platform（NKP）として結実している。NKPはクラスタのライフサイクル管理、セキュリティ/ポリシー管理、GitOps、可観測性などを標準搭載し、本セッションで紹介された共通プラットフォームと推奨ルート（Golden Path）の整備を一気通貫で支援するソリューションだ。
最後に町田氏は「本日お伝えしてきたGolden Pathの、最初の一歩を整備するところから始めてほしい」と呼びかけ、講演を締めくくった。
ニュータニックス・ジャパン合同会社からのお知らせ
本セッションでご紹介したサービスにご興味を持たれた方は、ぜひ公式サイトをご覧ください。
