このブログでは、AlibabaのエンジニアがDevOps、クラウド、Kubernetesについての考えを述べ、KubernetesがDevOpsに取って代わるのかどうかを取り上げています。
著者：アリババグループの技術者、孫建甫（田元）
DevOpsの考え方が提唱されたのは2007年のことでした。その頃は、クラウドとそれに付随するインフラの考え方が立ち上がったばかりでしたが、インターネットとクラウドが普及・浸透するにつれ、関連するアプリケーション、特にWebアプリケーションのニーズが爆発的に増えていきました。それに伴い、アプリケーション開発は、ウォーターフォールモデルからアジャイルモデルへと移行する必要がありました。
DevOps以前のアプリケーションは、複数のチームが関わる複雑なプロセスを経て納品されていました。最低限、このプロセスは、開発者チームから始まり、アプリケーションのデプロイと実行を担当するIT運用・保守チームへと続く必要がありました。しかし、この方法は比較的非効率的で、インターネット時代に必要なスピードには追いつきませんでした。
この問題を解決したのがDevOpsです。DevOpsは、開発チームと運用チームをつなぎ、アプリケーションのデリバリーサイクルを高速化し、アプリケーションの品質を向上させました。そして、アプリケーションの開発と提供の方法に革命をもたらしたDevOpsは、まったく新しい文化とプラクティスのシステムを導入し、それがWebアプリケーションの分野で普及しました。
しかし、クラウド・ネイティブやKubernetesによるアプリケーション管理が台頭してきた今、多くの人が疑問に思っているのは、DevOpsが存続するのかということです。このブログでは、アリババのテクニカルエキスパートであるJianboが、DevOps、クラウド、Kubernetesについての彼の考えを述べ、KubernetesがDevOpsを消滅させるのかという疑問に答えます。
DevOpsとは何だったのか、何が起こったのか？
黎明期のDevOpsは、瞬く間に人気を博しました。インターネット時代の黎明期に広く採用されたDevOpsは、品質が保証されたWebアプリケーションをアジャイルに開発したいという業界の要求を満たすのに役立ちました。また、DevOpsは、アプリケーション開発チームと運用チームがこれまで以上に密接に協力し合える「共通の空間」をもたらしました。当時、アプリケーション開発はまだ比較的新しい産業でした。
DevOpsが成功したのは、多くの点で過去の製造業の教訓から学んだからです。歴史的に見て、製造業が大規模な生産を実現できたのは、組立ラインが発明されたおかげです。特に、組立ラインの各工程を標準化したことで、作業者一人一人が自分の仕事やポジションを正確に把握できるようになり、製造工程がスムーズに進むようになりました。
DevOpsが過去の製造業の教訓を生かしたのは、CI/CDパイプラインモデルでした。このモデルは、puppet、chef、ansibleなどの一連の自動化ツールや半自動化ツールの開発をシミュレートするのに役立ちました。これらのツールは、コンパイルスクリプトのスケーラビリティを統合するとともに、開発・運用管理プロセスに関わるいくつかのオペレーションを標準化しました。
ひとつのプロジェクトに複数の技術者が関わる必要があったため、企業などのIT部門では「DevOpsチーム」と呼ばれる専門チームが一般的になりました。これらのDevOpsチームは、開発が最終的な本番環境に近づけるためのツールやプラットフォームとして機能し、アプリケーション開発の統合・配信プロセスにおいて、ワンクリックで簡単にデプロイやトラブルシューティングができるようになりました。これにより、アプリケーション開発の統合・配信プロセスにおいて、ワンクリックでのデプロイやトラブルシューティングが可能になりました。また、このプロセスでは、開発プロセス中に問題を取り除くことができるため、実際の本番環境では問題が発生しないか、もしくは発生する可能性が低くなります。
これまで見てきたことから、一つの結論として、DevOpsは多かれ少なかれ、アプリケーション開発の運用・保守面を簡素化するために設計されたと言えるでしょう。DevOpsは、一連の自動化ツールを通じて本番環境のO&M手順を提供し、そうすることで、従来の本番インフラストラクチャに関連するすべての細かい詳細に対処する必要性を排除しました。同時に、DevOpsはアプリケーションの問題点を開発初期段階で明らかにし、運用面での簡素化にも貢献しました。このように、DevOpsは運用側の利益のために構築されたのです。
これらの進歩と利点により、少なくとも最初はDevOpsが大きな人気を博し、多くのアプリケーション開発ワークフローの重要な一部となっていました。しかし、時が経つにつれ、DevOpsの世界の穴が明らかになってきました。DevOpsは、完全に持続可能な方法で構築されていませんでした。DevOpsは、企業に直接的な利益をもたらすものではなく、それに関連する製品がすぐにできるわけでもありません。実際、多くの企業にとってDevOpsは資産ではなく、コストとして関連付けられていました。
DevOpsは、しばしば大規模な専門チームを必要とするという点でコストがかかり、それを利用した企業の収益性が上がるとは限りませんでした。そのため、多くの企業はDevOpsへの投資に積極的ではありませんでした。そして時が経つにつれ、DevOpsは進化する開発者の要求に応えられなくなり、DevOpsの開発チームも、クラウドコンピューティングやオープンソースコミュニティの隆盛といった新しい業界のトレンドを念頭に置いて開発を続ける気がなくなっていったのです。このように、DevOpsは、いくつかの企業のアプリケーション開発・提供プロセスにおいて、徐々にボトルネックとなっていきました。
クラウド時代の到来とDevOpsの役割
クラウドはどのようにして始まったのでしょうか？それは、ある賢明な企業が、自分たちのニーズが業界全体のニーズや要求を表していることに気付いたことから始まります。それがAmazonであり、Amazon Web Services（AWS）が誕生した理由でもあります。アマゾンがパブリッククラウドサービスの世界に参入したことで、ITの世界は大きく変わりました。
2006年、アマゾンは世界で初めて、ネットワーク、コンピューティング、ストレージなどのITインフラの基本コンポーネントを、オンラインサービスとして米国内、ひいては世界中のユーザーに販売しました。このイノベーションにより、アマゾンのお客様は、自社のサーバーハードウェアや関連するITインフラを購入することなく、オンラインでサービスをホストしたり、ウェブアプリケーションを俊敏に開発する能力を持つことができるようになりました。
アマゾンをはじめ、AzureやAlibaba Cloudなどのクラウド分野の競合他社は、自社でITインフラを構築してホスティングするよりも、自社のサービスの方が安価になることで、クラウドを価値ある選択肢とすることができました。そして、クラウドとともに、IaaS（Infrastructure-as-a-Service）、PaaS（Platform-as-a-Service）、SaaS（Software-as-a-Service）などのクラウドの基本的なサービスモデルが生まれました。
クラウドコンピューティングの黎明期、主なサービスモデルはIaaSでした。IaaSでは、主に企業レベルのお客様が、ウェブサーバーや仮想マシン、必要な関連ストレージをクラウドサービスプロバイダーから購入することができました。また、IaaSのサービス構造では、お客様は提供されたインフラをどのように運用・保守するかを完全にコントロールすることができました。もちろん、IaaSが従来のITと違うのは、メンテナンスの対象が物理的なサーバーではなくなったことだけです。つまり、結局は何も変わらないのです。
そして、クラウドコンピューティングが今日のように急速に進歩していく中で、クラウドの機能は強化され、充実していきました。クラウド上で提供される製品やサービスは、最終的にITの運用・保守面のさまざまな側面や機能をすべてカバーするようになりました。それは、コーディングやホスティング、統合や配信、監視、アラームシステム、オートスケーリング機能に至るまで、アプリケーションのライフスタイルの管理に関わるすべてのサービスを含みます。
この急速に変化するITの世界において、DevOpsはほとんど変化しませんでしたが、それでも使い道はありました。クラウドへの接続は、特に初期の頃は難しいかもしれません。クラウドサービスプロバイダーは、複雑で多様なサービスを提供しており、各プロバイダーのサービスのポートフォリオは全く同じではありません。そのため、お客様はクラウドサービスの仕組みを認識・理解し、クラウドに移行する際には1つのベンダーに縛られないようにする必要があります。こうした判断は簡単ではありません。
一方、DevOpsはこの間、ほぼ変化がなく、それが結果的にお客様の信頼を高め、導入のしやすさにつながりました。また、クラウドが登場しても、DevOpsはこれまでと同じように複雑な開発環境をシンプルにすることができました。唯一の違いは、管理すべき基本的なITインフラがクラウド上で稼働するようになったことです。つまり、そのシンプルさゆえに、DevOpsはまだ市場に存在していたのです。
Kubernetesとは何か、そしてそれがどのようにすべてを変えるのか
さて、DevOpsの世界を揺るがすITの次なる大物、Kubernetesについて説明しましょう。そもそもKubernetesは、最新のアプリケーションインフラとして設計されました。Googleのクリエイターたちは、アプリケーションとクラウドをより直感的に統合し、クラウドの可能性を広げるものを作りたいと考えていました。そして、Kubernetesの最終的な目標は、基本的なITのあり方を変えることであり、アプリケーションに適した、より効率的なアプリケーション配信システムを実現することでした。
Kubernetesは、DockerやOperatorとともに、クラウドネイティブ時代のクラウドコンピューティングの世界で重要なオープンソースプロジェクトとなりました。これらのプロジェクトは、アプリケーションの管理と配信の世界を全く異なるものにしました。特にKubernetesでは、開発者は宣言型の構文を使ってアプリケーションの最終的な状態をコントロールするだけで、あとはすべてKubernetesが引き受けてくれました。
このシンプルさが、Kubernetesを非常に人気のあるものにしました。宣言型のAPIアクションは、Kubernetesがクラウドの仕組みのすべてを破壊するほどの力を持っていたからです。そして、それは昔も今も強力なツールです。Kubernetesのユーザーは、宣言型APIアクションを使って、多種多様な状態を素早く簡単に宣言することができます。その能力は非常に高く、しかも責任は大幅に簡素化されていました。
今日では、アプリケーション開発者として、アプリケーションの最終的な実行状態を制御するためにKubernetesの宣言型構文を使用できるだけでなく、アプリケーションの運用関連部分のいくつかを宣言するためにも使用できます。例えば、カナリアリリース方式でアプリケーションを更新することや、CPU使用率が50％を超えたらアプリケーションを追加インスタンスに拡張することを宣言することができます。
これは、DevOpsツールやチームにとって大きな課題となりました。というのも、宣言型APIアクションを使用するだけで、アプリケーションを完全にコントロールできるだけでなく、いくつかのサービスレベルの機能も利用できるのであれば、誰もがアプリケーション開発のニーズに合わせてKubernetesに乗り換えることになるのではないかと思ったからです。それがまさに問題だったのです。問題は、人々がDevOpsのCI/CDパイプラインを学ぶ正当な理由があるかどうかです。
言い換えれば、長い間、DevOpsは、アプリケーション開発とそれに関連する基本的なITインフラを結びつける論理的な「接着剤」でした。しかし今では、Kubernetesとその完全装備の宣言型APIアクションがアプリケーション開発インフラの隅々にまで浸透したことで、Kubernetesはむしろインフラの「接着剤」の役割を担うようになっています。同時に、DevOpsの過去の地位がKubernetesによって問われていたように、従来のミドルウェアもService Meshの大きな津波に叩き落とされていました。
では、DevOpsは地球上から消えてしまうのか？
さて、DevOps、クラウド、そしてKubernetesを手に入れたわけですが、DevOpsの次はどうなるのでしょうか。ここ数年、Kubernetesはクラウドの文脈でDevOpsの完璧なパートナーと言われてきました。
同様に、KubernetesはDockerのように、アプリケーションのランタイムに関する問題を解決できるという考えも存在します。この点、Kubernetesは、アプリケーションランタイムの責任を仮想サーバーから奪ってコンテナに与えた、一種のファッショナブルなバージョンのIaaSと例えられています。つまり、DevOpsに関連する既存の考え方やプロセスをKubernetesに結びつけさえすれば、コンテナ技術の軽量性と拡張性を享受することができるということです。もちろん、DevOpsがアジャイル開発を推進してきた実績を考えれば、DevOpsとの相性は良いと言えるでしょう。
しかし、今わかる範囲では、これは完全な話ではありません。Kubernetesの今後の開発ロードマップでは、Kubernetesが将来的にIaaSの役割を担うことはありません。むしろ、Kubernetesはアプリケーション開発の基盤となる技術インフラの機能を変えることに焦点を当てていますが、Kubernetesはそれ自体がインフラとは程遠いものです。もっと言えば、アプリケーションのランタイムに関して言えば、Kubernetesはむしろアプリケーションのステータスやアプリケーションのライフサイクルを重視しています。また、これ以外にもKubernetesは「コントローラモデル」と呼ばれる、アプリケーションの実際の状態をより理想的な状態に近づける機能を提供しており、典型的なアプリケーションランタイムの管理をはるかに超えています。
つまり、Kubernetesはアプリケーションそのものを対象としており、IaaSシステムの基本インフラとは大きく異なり、インフラの「接着剤」としての地位を確固たるものにしているのです。もちろん、Kubernetesの機能が十分で、アプリケーション開発と基盤インフラの間の接着剤としての役割を果たすことができるのであれば、DevOpsはどこに位置するのでしょうか？DevOpsは存在する必要があるのでしょうか？いわゆるクラウド・ネイティブの時代に、アプリケーションを宣言するだけで、あとはすべてうまくいくのでしょうか？ そして、DevOpsは地球上から消えてしまうのでしょうか？
しかし、このような見方は、現実と完全に一致しているわけではありません。これを実現するためには、Kubernetesにはまだいくつかの欠点があります。
Kubernetesは典型的な「Platform for Platform」プロジェクトなので、そのAPIアクションは真の開発ツールとは程遠いものです。例えばデプロイメントオブジェクトを考えてみると、開発側が気にするイメージだけでなく、インフラ側のリソース設定、さらにはコンテナのセキュリティ設定なども含まれています。これらはKubernetesだけで実現できるものではないので、「宣言したら終わり」というのは現実離れしています。これは、DevOpsが現在でも有効である理由でもあります。Kubernetesのほとんどの文字列については、やはりDevOpsが行うもので補う必要があります。
次に、KubernetesのAPIには、ストレージ購入のためのPV/PVCやロードバランシングのためのIngressなど、必要なクラウドリソースのほんの一部しか含まれていません。そのため、Kubernetesが苦手とすることがたくさんあります。例えば、開発者がKubernetesだけに頼らなければならない場合、データベース、VPC、メッセージキューに関することを表現するのに、Kubernetesの宣言的な構文を使うのは難しいでしょう。DevOpsはこれを支援します。また、既存のソリューションは、特定のベンダーの実装に依存しており、ベンダーロックインの問題が発生する可能性があります。
最後に、KubernetesのOperatorメカニズムは、Kubernetesの機能がこれほどまでに成長できた理由の秘密です。しかし、一つの大きな問題は、Operator同士が相互に作用できないことです。例えば、あなたがCRDとOperatorを介してRDSをKubernetesの宣言型APIシステムに取り込んで拡張した後、他の誰かがあなたと協力してRDSの永続ファイルを定期的にバックアップするCRD Operatorを書きたいと考えたとします。DevOpsのシステムが介在しないと本質的には無理な話ですが。
将来はどうなるのか？
以上の議論から、既存のKubernetesプロジェクトは、高効率のアプリケーションの反復と配信タスクを完了するために、依然としてDevOpsに依存していることが明らかになりました。これはやむを得ないことです。アプリケーション中心のインフラとしてKubernetesがプッシュされていても、現実には、Google Borgから生まれたシステムレベルのプロジェクトとして、Kubernetesはまだ他のいくつかの既存のインフラ要素を中心に展開し、それに基づいて機能しているのです。
ただ、否定できないのは、KubernetesがNoOpsの追求を目的としていることです。これは最初から明らかでした。その後、CRDやOperatorといったシステムができたことで、Kubernetesのアプリケーションレベルでの懸念が現実のものとなりました。興味深いことに、多くのDevOpsプロセスがKubernetesの宣言型オブジェクトや制御ループになっていく様子も見られるようになってきました。Tekton CDプロジェクトはその一例です。
もしKubernetesの未来が宣言型のアプリケーション管理とNoOpsのためのものであるならば、DevOpsはいずれ技術的な分野からは消えていきますが、ITの世界では一種の文化遺産として残っていくだろうと考える理由もあります。結局は、DevOpsが盛り上がった頃の運用・保守エンジニアが、KubernetesのControllerやOperatorのコンパイラや設計者になるのではないかと考えています。
本ブログは英語版からの翻訳です。オリジナルはこちらからご確認いただけます。一部機械翻訳を使用しております。翻訳の間違いがありましたら、ご指摘いただけると幸いです。
アリババクラウドは日本に２つのデータセンターを有し、世界で60を超えるアベラビリティーゾーンを有するアジア太平洋地域No.1(2019ガートナー)のクラウドインフラ事業者です。
アリババクラウドの詳細は、こちらからご覧ください。
アリババクラウドジャパン公式ページ