CNDO2021、Kubernetesがない世界とある世界の違いをインフラエンジニアが解説
CloudNative Days 2021 ONLINEでは、クラウドネイティブなシステムを想定するゴールとしてシステムに使われるソフトウェアを解説するセッションが主なコンテンツとなっている。今回は「クラウドネイティブではすでにデファクトスタンダードであるKubernetesを使わなくてもクラウドネイティブは実装できるのか?」を解説するセッションを紹介したい。タイトルは「Kubernetesがない世界線のCloudNativeジャーニー」で、プレゼンテーションを行ったのはあさぎ氏だ。
最初にレガシーなシステムにおける開発から本番環境への実装を図式で解説。ここではデベロッパーがコードを書いてGitリポジトリーへのPushを行い、JenkinsがそれをフックにしてArtifactを生成し、最終的に運用担当者が実装する流れを示している。Gitリポジトリー、Jenkinsという名前が出てくることからわかるように、このセッションにおける「レガシー」は「CI/CDまではできているが、Kubernetesが入っていない世界」を指している。
次にクラウドネイティブなシステムに至るまでの段階を解説したこのスライドでは、ゼロから作り直す方法と、リフト&シフトする方法について説明している。
既存システムがある状況では、ゼロから作り直す方法はビッグバンリライトとして時間だけがかかる割に既存システムと変わらないシステムができてしまうことを説明し、現実的な解として徐々にシステムを置き換えていくリフト&シフトが良いことを解説した。しかしその場合でもコードのリファクタリングは必須であり、機能や依存性の分解、テストの書き直しなどが必要になり、単にクラウドにリフトしただけではホストを変えただけのリホストになってしまうと強調した。
ここであらためて「クラウドネイティブとは何か?」を再確認する意味でCNCFの定義を参照し、その中で重要なキーワードを抜き出してポイントを整理した。
その中からクラウドネイティブにするための最終的なゴールは「素早く継続的にユーザーに価値を届ける」ことであり、そのために「変更を最小限の労力で頻繁かつ予測どおりに行う」必要があることを解説した。
このようなシステムには、スケーラブル、回復性、可観測性、堅牢な自動化、管理のしやすさ、疎結合という特性を備えたソフトウェアが必要であると説明した。
先ほどのレガシーなシステムに対比して、Kubernetesがある世界として挙げたのがこのスライドだ。ここではデベロッパーがコードをGitにPushし、それがコンテナイメージとして生成され、その実装方法をManifestとして運用担当者がコードを書いて、最終的にKubernetesが導入されたシステムに実装されていく流れを説明した。
Kubernetesがある世界ではコンテナによって可搬性が上がること、宣言的であることなどがメリットとして強調された形になっている。その一方、組織としてKubernetesについて理解を深め、常にその進化にキャッチアップしていく必要があることが課題として敢えて挙げられている。
このスライドでのポイントは、Kubernetesを取り除いてもシステムとしては実現できることだろう。「素早く継続的にユーザーに価値を届ける」というシステムのゴールに、Kubernetesの存在は前提ではないことを説明した。
この文脈では、これまで使っていたレガシーなシステムのツールを使ってコードだけをリファクタリングして整理分解すれば、Kubernetesを学ぶというコストを支払わなくてもクラウド的なシステムは作れるはずであると説明している。
このスライドではKubernetesがある世界とない世界の比較を示している。ある世界は宣言的、ない世界は命令的(手続的)で、成果物と管理対象もそれぞれ異なっていると整理して解説を行った。Kubernetesの特徴である宣言的なシステムであることには触れられている一方、Kubernetesが持つ自動修復やスケーラブルな特性をレガシーなシステムでどのように実装するのかについては触れられていないのは興味深い。
このスライドでは両方の世界に共通する項目を挙げている。テストを書いて実行し、CI/CDを頻繁に行うことや自動化、インフラのコード化が必須のポイントとして強調されている。「分散モノリス」というのは矛盾しているような用語だが、モノリシックなアプリケーションがネットワークを介して分散連携しているようなシステムを指すのだろう。これはリファクタリング不足の産物なのかもしれない。
次にKubernetesがない世界の落とし穴として紹介したのがこのスライドだ。
ここでは、デベロッパーと運用が分離しながらもオーバーラップする領域があることでオーバーヘッドが発生し、開発から実装までのサイクルが素早く回らないことを最初の欠点として挙げている。だが実際にはその問題を解決している例もある。CloudNative Day Tokyo 2020でメルペイが発表したセッションでは、開発から運用までも同じチームが行うことでサイクルを加速し、異なるチームにおいても使うツールや言語を統一して技術スタックの差をなくしていることを解説している。
参考:CNDT2020シリーズ:メルペイのマイクロサービスの現状をSREが解説
メルペイの手法は、あらゆる企業に適用できるものではないだろう。しかしあさぎ氏も次のスライドで開発から運用までを同じチームで行うことやツールやインフラの共通化を提案しており、この発想が現実的な解として理解されていることがわかる。
特に組織についてはTeam Topologiesを引用して複数のチームについて解説を行った。
このスライドにおけるStream-aligned Teamは開発から運用までを行う。Enabling Teamは機械学習など特化した分野での開発を支援する専門チームであり、Platform Teamはプラットフォーム自体の運用管理を行うものだ。Platform Teamの役割は単にインフラを運用するのではなく、開発チームがセルフサービスで運用を行えるようなプラットフォームを開発して提供するというものであり、レガシーな運用チームとは大きく異なる部分だろう。
さらにその組織の持つ役割についても言及し、レガシーな世界からクラウドネイティブの世界への移行に際し、組織がどう変わっていくのかを説明した。
ここではStream-aligned Teamが開発から運用までをカバーし、それを専門チームであるSREが支援するという形態を取っている。MicrosoftのMark Russnovich氏が「Kubernetesはデベロッパーにとっては難しい」として提案したアプリケーションオペレーターという中間的な役割の考え方を導入すれば、アプリケーションオペレーターもの開発チームに含まれることになるのだろう。
そしてKubernetesがない世界においては、Kubernetesに対する学習コストが不要になる代わりにKubernetesが担っている役割を自身で開発もしくは用意する必要があること、組織も変化に対応できるように変わっていく必要があることなどを示した。Kubernetesがなくてもクラウドネイティブになることは可能であるが、実際には難しいことを指摘した。
最後にまとめとして、クラウドネイティブにKubernetesは必ずしも必須ではないが、Kubernetesに乗ることで不要な労力をなくすことができる、開発チームが運用までカバーすることなどを解説してセッションを終えた。
このセッションであさぎ氏の解説する「レガシー」が、比較的新しいシステムに見えてしまうのは筆者がこの業界を長く見ているからかもしれない。
組織の構成にまで踏み込んで解説していることは興味深いと言える。日本の企業ではDevOpsが組織の壁に阻まれてしまう例も多数存在することを考えると「組織の構造がソフトウェアにも反映する」というコーンウェイの法則を理解した上で、それを打破するためには組織もツールも変わっていくしかないという提案として有効だろう。
連載バックナンバー
Think ITメルマガ会員登録受付中
全文検索エンジンによるおすすめ記事
- CloudNative Days Tokyo 2019:あえてK8sを選ばなかったSoftBankペイメント
- CNDT2020シリーズ:メルペイのマイクロサービスの現状をSREが解説
- CloudNative Days Tokyo 2019:メルペイのマイクロサービス化の目的とは?
- CNDT2020シリーズ:プロジェクトからプロダクトへ。強いチームを作るコツをVMwareのアーキテクトが語る
- CNDT2021、日本オラクルのエンジニアによるクラウドネイティブを再確認するセッション
- CNDT2021、パブリッククラウドを使ってゼロから勘定系を開発したみんなの銀行のセッションを紹介
- KubeCon Europe 2024、ID管理のVenafiのVPにインタビューを実施。マシンID管理とは?
- CloudNative Days Spring 2021開催。CNCFのCTOが語るクラウドネイティブの近未来
- IBMとRed Hatが推進するレガシーアプリケーションをKubernetesに移行するためのツールKonveyorを紹介
- CloudNative Days Tokyo 2021が11月に開催 記者会見で見えた「繋げる」の意味