Kubernetesへの移行を成功させるには


Kubernetesを活用したいけど、単にアプリケーション開発の効率を高めるだけでなく、開発プロセスの変革をともなうので気軽には導入できない、と考えている開発チームは多いと思います。

それは、たしかにそのとおりで、これは気軽に手が出せないKubernetesの課題とも言えますが、同時にKubernetes最大の利点でもあります。つまり、考え方次第では、Kubernetesを導入すれば、アプリケーション開発が便利になるだけでなく、開発プロセス全体を根本的に改善する絶好の機会になる、と捉えることができます。

とは言え、余裕があれば、ぜひ開発プロセスを改善したいけど、日常業務で手一杯でそんな余裕がどこにあるんだ!と言う声が聞こえてきそうです。余裕はその辺に転がっているものではなく、自分で作り出すものなぁんですぞぉ~と仙人口調で正論を返したら、現場との議論は永遠にかみ合わないことでしょう。

本来、Kubernetesによる効率化は余裕を作り出す手段のはずなので、最初の一歩を踏み出せば、それが先行投資となって、後のちに劇的な改善を見るはずなのですが、最初の一歩が大きすぎて・・・

つまり、重要なのは最初の一歩をなるべく小さくすることです。

Kubernetes migration: 4 secrets to a smooth move(Kubernetesマイグレーション: 円滑な移行のための4つの秘訣)という記事が示唆に富んでいるので、参考にしてみてください。Kubernetes導入へのハードルを低くするための、識者による意見がまとめられています。ここでは、その各識者の生の声を引用して、日本語で解説してみたいと思います。

Kubernetes migration is not just about technology, but people and culture also.” ― Kasten社CEO、Niraj Tolia(Kubernetesマイグレーションは技術面の問題にとどまらず、人と文化の問題でもあります)

Culture(文化)とは、芸術的なことではなく、日本語でも「企業文化」と言ったりしますが、つまり、その組織のメンバーに根付いた考え方や行動パターンのことです。Kubernetesは単なる開発ツールではなく、組織のあり方を変える起爆剤になりうるので、先に挙げたKubernetes導入の課題と利点がこのTolia氏の言葉にすべて集約されています。換言すれば、Kubernetes導入前に、チーム内にその意識が醸成されていれば、導入が円滑化されるということです。それは、後で出てきますが、DevOpsやCI/CDと同じ考え方で、Kubernetesで効率化された開発・テスト・運用といった一連の流れには組織の全員が関わることであり、全員にその準備があれば、Kubernetes導入の効果が最大限に引き出される、と考えられます。

マイグレーション成功の秘訣その1:低リスクのものから段階的に慎重に進める

“Think twice about a big-bang migration. Start with the white-glove treatment, migrating low-risk projects carefully.”(ビッグバン マイグレーションはよくよく考えたほうがいい。むしろ、低リスクのプロジェクトから慎重に、白手袋で貴重品を扱うような丁寧さで)

同じくTolia氏の言葉です。ビッグバンは大袈裟な比喩ですが、社内システム一斉大改革的なことでしょう。それができるに越したことはないですが、それができないから今こういう記事を書いています。Kubernetes導入のハードルを低くするには、低リスクのシステムから先に、なるべく慎重に、白手袋でモナリザの原画を手入れするような感覚で… これも大袈裟ですが、要するに最初の一歩は足元のしっかりした安全なところから慎重に踏み出しましょう、ということです。

“Like any migration, incremental wins and lowest-hanging-fruit approaches will build confidence in the migration” ― Harness社DevOpsエバンジェリストRavi Lachhman(すべてのマイグレーション同様、段階的に少しづず、達成しやすいところから達成して、自信を深めながらマイグレーションを進めるべき)

「木の上のほうではなく、手に届く高さにぶら下がっている実から取りましょう」は、「低リスクのプロジェクトから始めよう」と同義です。低リスクから始め、徐々に対象を広げていくことが重要です。そうすれば、チーム全員の成功体験の積み重ねにもなるし、やがて皆、キリンのように首が長く進化して、木の高いところの実も食べられるようになるでしょう。千里の道も一歩から、やがて麒麟がくる!です。

“Using frequent milestones is key to driving any migration and is especially important when moving applications into Kubernetes, since this often represents a fundamental shift in the way infrastructure is run.” ― Kasten社エンジニアリング リードTom Manville(段階的に目標を定め、一つひとつクリアして行くことは、Kubernetesマイグレーションでは特に重要です。それがやがてインフラストラクチャの根本的な移行につながるので)

段階的に進めていくこと、チーム全体で目標を定め、一つひとつクリアして行くことが大切なのはわかりましたが、では何から始めましょうか?

マイグレーション成功の秘訣その2:適したアプリケーションを見極める

“Looking for apps where modernization would make big-picture sense.”(最新式への変革が大局的に意味を成すアプリケーションから着目を)

つまり、Kubernetesでの効率化が組織全体(特に、開発と運用チームの両方)を利するのか?を考慮する必要があります。これも結局、DevOpsと関連しますが、Kubernetesによる開発プロセスの効率化/高速化が、ありとあらゆるアプリケーションと組織に適切というわけではないので、適正は考慮されなければなりません。プロセスそのものはどんなシステムであれ効率化すればするほど良いはずですが、チームがそれに追いつかなければ意味がない、どころか逆効果ということは、現実には多々あることです。

“Lift-and-shift can be okay, but focus on net-new cloud-native applications or refactoring”(まるごと移動してそのまま嵌め込めるなら何よりですが、クラウドネイティブ アプリケーションを一から設計するか、コード修正を検討することも重要)

これもKastenのTolia氏の言葉で、真意が伝わるように意訳しました。コーディングしなおさずにKubernetesに移行できればそれに越したことはないですが、無理やり嵌め込むのは絶対に避けるべきです。コンテナ化されていないのであれば、マイクロサービスを実践するアーキテクチャを一から構築しなおす、あるいは、それに合わせた抜本的な修正も必要になるでしょう。Kubernetesマイグレーションを機にそれをやらずに楽をすると、逆にあとで面倒が増えるので、ここはひとつ頑張り時ということで、朝礼で「蟻とキリギリス」にちなんだ訓示でもして、チーム一丸取り組みましょう。

“For applications getting containerized for the first time, it is important that the dependencies and access to them are clearly mapped and planned.” ― Altran社テクノロジー研究イノベーション ディレクターRaghu Kishore Vempati(初めてコンテナ化するアプリケーションは、各要素の相互依存とアクセスの関係を明確に配置し、その構成を理解し、展開を準備するのが大切)

すでにコンテナ化されているアプリケーションは、マイグレーションが比較的容易なのは言うまでもありません。コンテナ化されていないアプリケーションは、Tolia氏の言う「クラウドネイティブのためのリファクタリング」が必要になるのですが、それをするにはまず相互依存関係の分析が不可欠です。

上の発言のVempati氏は”measure twice, cut once”(2回測って1回切る)が重要だとも言っているのですが、実行に移す前の計画性がコンテナ化においては特に求められます。たとえば、コンテナ化されたアプリケーションがKubernetes上からコンテナ化されていないアプリケーションにアクセスする依存関係があって、なおかつ、それらが同じクラスタにある場合などは特に「アプリケーションの全体的なフローを何度も検証する必要がある」と同氏は具体例を挙げて強調しています。

次回は、Kubernetesマイグレーション成功のための4つの秘訣の残りの2つに続きます。

関連トピックス