オープンソースインフラの新しい10のルール

by Alex Cattle on 1 November 2019

7月に開催されたCloudNative Days Tokyo / OpenStack Days Tokyoで「The 10
new rules of open source infrastructure（オープンソースインフラの新しい10のルール）」と題して講演しました。反響は良く、Twitter上では10のルールの詳細をもっと知りたいというコメントがありました。説明が分かりやすかったという感想もありました。そこで、ここに講演の要点をまとめましたので、ぜひご意見をお聞かせください。この分野における過去10年の変遷についてさらに議論を重ね、新しいルールを追加できれば幸いです。私は、インフラITにも持続的な概念や原則があり、それらを明確にすることが、この分野の次世代思考につながる意思決定にとって重要だと考えています。

1.アップストリームに変更を加えず使用

ベンダーがアップストリームプロジェクトをベースにインフラソフトウェアの「硬化」バージョンをリリースすることで、オープンソースのプロジェクトが「エンタープライズ対応」していると主張する時代は終わりました。現在ではOpenStackは複数のリリースにわたり安定していて、一切のベンダー介入なしに最新のユースケースやワークロードに対応することができます。CERNやAT&Tが良い例です。

私はこれが最も重要なルールだと考えています。なぜならこのルールを守らないと、自分の首を絞めることになるからです。ダウンストリームのパッチを適用することによって、本稼働プラットフォームで作業したり、サポートや革新に従事したりする人数を制限するのはおかしな話です。オープンインフラの本質は、より大きなコミュニティとサポートのために連携し、次世代インフラプラットフォームで採用、トレーニング、およびイノベーションをおこなうための共通基準を作ることです。

2. 製品としてのインフラ

次世代インフラを実装するということは、本質的には競合する代替技術のある市場に参入するということを覚えておくべきです。ほとんどの場合はパブリッククラウドの代替技術ですが、VMwareなどの古い技術に基づくレガシースタックも、特にワークロードの採用に時間がかかる場合は大きな脅威になる可能性があります。開発者と連携して新しいプラットフォームへのワークロードの移行に積極的に取り組むことは、競合プラットフォームよりも低いコンピューティングユニットあたりのコストを達成するためには不可欠であり、このレベルにできるだけ早く達する必要があります。

また、インフラは「手作り」であってはなりません。大規模な実装は、例外なく標準コンポーネントで構成されていて、アーキテクチャとパラメータチューニングが簡素化されています。既存クラスターに関する知識を新しいチームへの移行する、あるいは新規スタッフをトレーニングしたり「エキスパートの退職」からチームを立て直したりする必要性を無くすことがポイントです。これを実現するには、インフラに技術的な負債をもたらす、カスタマイズされたリファレンスアーキテクチャを避けるしかありません。

3. 1826日後の自動化

ほとんどのチームは、理想レベルの自動化を達成していません。そして、それを自覚していても、何もしていないのが現状です。特定のツールがオペレータに好まれるようになった理由は、自動化ユースケースの最初の8割にかなりうまく対処しているからですが、それは残りの2割への対処を犠牲にしたうえに成り立っています。結果として、アップグレード、カナリアリリース、拡張リリースといったライフサイクルイベントは複雑なままで、それらに費やす労力を減らすことができません。もし、何かタスクを実行するためにサーバーにSSH接続する必要があるとしたら、自動化は不十分だと言うことです。そのマシンに関するすべてのイベントは、APIを介して、そして包括的な自動化およびオーケストレーション設定によって処理される必要があります。

オーケストレーションの自動化方法を選ぶ際は、ハードウェアの償却期間（通常5年）にテクノロジースタックが変化することを想定してください。今日のVMwareは明日のOpenStackかもしれません。あるいはOpenStack上、またはそのすぐ横にあるベアメタル上でKubernetesクラスターになっているかもしれません。はたまた完全にOpenStackに取って換わられているかもしれません。どうなるかは判りません。一旦「サーバーレスのKubernetes」が実現すると、そのテクノロジーの展開と統合を自動化する必要が出てきます。アップストリームのイノベーションサイクルが短くなり、年間のリリース数が増えるなか、これらのイベント間で同じオペレーションパラダイムを維持することが今まで以上に重要になります。

4. オンプレミスの容量で稼働。パブリッククラウドはオーバーフローとして使用

データセンターの経済性を最大化するのなら、必然的にオンプレミスインフラをできるだけ容量いっぱいまで稼働させる必要があります。ハードウェアは投資に対して最大の価値が提供できるものを選ぶべきです。それは必ずしもその投資自体の最低コストではないかもしれませんが、全体として最も高い経済性につながります。特に、パブリックな代替手段と同等のコスト構造を目標にする場合はこのことが重要です。

ただし、このルールは、パブリッククラウドを避けるという意味ではないことに注意してください。それどころか、組織の経済面での要件を満たす堅実なオンプレミス戦略に加えて、最低2社のパブリッククラウドプロバイダーと連携することをお勧めします。パブリッククラウドパートナーが2社あることで健全な競争が生まれ、運用においてクラウドニュートラルな自動化が実現されます。これはマルチクラウド戦略の成功にとって重要な側面です。パブリッククラウドの認定管理者がいるのは良いことですが、クラウドAPIに依存しない自動化のほうがより望ましいでしょう。

5. バックポートではなくアップグレード

Ubuntuはこのパラダイムを常に支持してきましたが、これはオープインフラでも引き続き当てはまることです。アップストリームプロジェクトのサポートサイクルが短くなっているため（たとえばOpenStackやKubernetesのサポートされているリリースやメンテナンスウィンドウの数を考えてみてください）、導入後に訪れるあらゆるライフサイクル管理イベントのコストを悪化させるような技術的な負債を抱えるのではなく、アップグレードする習慣を身につけることが、最も重要なルールの一つです。適切な自動化プロセスが整っていれば、アップグレードは予測可能となり、妥当な時間内で解決できるようになります。インフラを製品として実行し、アップストリームコードを変更せずに消費することは、この予測性を高める要因となります。これがなければ、規模を問わず、アップグレードはほぼ管理不可能なタスクとなってしまいます。

6. ワークロードの配置の重要性

ある意味、これは理解できると思います。プライベートクラウドを導入する本質的な理由は、ワークロードについて悩みたくないからです。しかし実際には、どんな種類のデバッグベースラインも通常は構築することはほぼ不可能なのです。クラウドは本質的に動的であるため、サービスレベル違反発生時のデバッグでは、クラウドというインフラが持つ変化する性質を考慮する必要があります。ある程度のサイズのクラウドは、この問題を抱えています。ほとんどの運営チームは、ベアメタルレベルで起こっていることは、仮想レベルおよびコンテナレベルまで関連していなければならないということを無視しています。消費可能なコンピュートの単位が小さいほど（仮想マシンやコンテナのサイズを考えてみてください）、一般的に環境はより動的になり、導入するレイヤー数が多くなるにつれて現象と根本原因の因果関係を見つけることは飛躍的に難しくなります。テナントを搭載し、コンテキストの中でそれらのイベントをキャプチャするために必要なテレメトリを構築するときのワークロードの配置を考えてみてください。それにより予測分析、そして最終的にはオペレーションへのAIの導入へとつながるのです（クラウドインフラが大規模で複雑なほど、AI導入の緊急性は高まります）。

7. 移行の計画

先にも述べましたが、特定のハードウェアがその寿命を通して特定のインフラに固定されると考えることは非現実的です。このことはエッジのユースケースで顕著に示されています。特に通信事業者におけるエッジでは、ワークロードの一部がコンテナ化され、残りはVMやベアメタルのまま運用されるという変化が今後3年で起こり、それらの要件に対処する必要が出てきます。したがって、エッジの性質と管理要件は今後3年で進化していくでしょう。その結果、コンテナ化された「最終状態」ではなく、移行状態に向けた設計を行うことが重要になります。この設計目標を達成するためには、ベアメタルプロビジョニング、仮想マシン管理、OpenStackおよびKubernetesを通した完全自動化、そして同一の運用パラダイムが重要な役割を果たします。

8. セキュリティは当然

あくまでセキュリティパッチはパッチであり、セキュリティオペレーションはオペレーションです。クラウドプロジェクトは開発者とオペレーションチームが考案することが多く、通常は別のチームである「セキュリティチーム」が関わることは、まれです。そうなると、セキュリティチームは、議論を重ねてロールアウトの計画が策定された後に決まったことを知らされることになり、多くの場合それらの計画にケチをつけるような反応をするのです。セキュリティとは、最初から示すべき心構えや姿勢であり、要件の一部として継続的に注力しなければなりません。セキュリティは特別なものではなく、利害関係者の期待に応えるためにクラスターが満たさなければならない他の機能外要求と同様に重要です。プロセスがだいぶ進んでからやり直すことのないように、セキュリティを早期に、頻繁に、そして緊密に関係させることが必要です。

9. 「光り物」を受け入れる

オープンインフラの本質は、次世代アプリケーションのロールアウトを加速させることで、イノベーションを育て、企業の競争優位性を高めることです。邪魔をしないようにしましょう。開発者がコンテナを要望したら、受け入れましょう。開発者がサーバーレスを要望したら、受け入れましょう。新しいテクノロジースタックを「光り物」としてあざ笑うのではなく、ソリューションに直接関与して初めて、既存のオペレーションパラダイムや自動化の不備が見えてきます。仕事の後にビールを飲みながら論評するのは楽しいですが、そこで終わらせましょう。

10. エッジを意識し、Microを始めよう！

少し話がそれますが、私がCanonicalで現在取り組んでいる2つの革新的なプロジェクトをご紹介します。

MicrostackはOpenStack Edgeユースケース向けのプロジェクトで、現在はベータ版です。OpenStackのフルクラスターを1つのノードにインストールし、一般に利用可能になった後は限られたクラスタリングをサポートします。このプロジェクトは、Snapアプリケーションのコンテナフォーマットを使用して、明確で簡潔な形式のスモールフォームファクターOpenStackの要件の大半をエレガントに解決するもので、私はとてもワクワクしています。革新的でサイズも小さく、注目に値します。

Microk8sはKubernetesにおいて同様です。Microk8sは、互換性のあるLinuxディストリビューションにインストールする単一のSnapパッケージで、Istio、Linkerd、Knative、Kubeflowなどのサービスメッシュをプロビジョニングするための豊富な機能を持つアドオンシステムを装備しています。詳細はmicrok8s.ioをご覧ください。

両方ともSnapとして配布されるため、IoT/デバイス環境、またクラウド/データセンター環境で使用できます。1つのコマンドでインストールできます。

$ snap install microstack –beta –classic

$ snap install microk8s –classic

おわりに

クラウド業界において、この10年間に見てきた所見を10の新しいルールとして明文化しました。最初に十戒を持ったモーセの画像を示しましたが、これらのルールを「戒律」として考えているわけではありませんし、私はもちろんモーセではありません。OpenStackアーキテクトおよび製品マネージャとして、私がこの10年間で観察してきたことをまとめたものです。