Kubernetes を恐れる必要がない理由

90 年代後半から 2000 年代初頭にかけて、大規模な Web サイトに取り組むのは楽しかったです。私の経験は American Greetings Interactive を思い出させます。バレンタインデーには、私たちのサイトはインターネット上のトップ 10 サイトの 1 つでした (Web トラフィックで測定)。当社は、AmericanGreetings.com や BlueMountain.com などの企業や、MSN や AOL などのパートナー向けに電子カードを提供しています。この組織のベテランたちは、ホールマークのような他の電子カードサイトとの壮大な戦いを今でも懐かしく思い出している。ちなみに、私は Holly Hobbie、Care Bears、Strawberry Shortcake などの大規模な Web サイトも運営しています。

[[281366]]

昨日のことのように覚えていますが、本当に問題が起こったのは初めてでした。通常、私たちの玄関口（ルーター、ファイアウォール、ロードバランサー）には約 200 Mbps のトラフィックが流入します。しかし突然、Multi Router Traffic Grapher (MRTG) のグラフが数分のうちに 2Gbps まで急上昇しました。私は狂ったように走り回っていました。私は、ルーター、スイッチ、ファイアウォール、ロードバランサーから、Linux/Apache Web サーバー、Python スタック (FastCGI のメタバージョン)、ネットワーク ファイル システム (NFS) サーバーに至るまで、当社のテクノロジー スタック全体について学びました。私はすべての設定ファイルの場所を知っており、すべての管理インターフェイスにアクセスでき、複雑な問題のトラブルシューティングを長年行ってきた熟練したシステム管理者です。

しかし、何が起こっているのか分かりません...

1,000 台の Linux サーバーで必死にコマンドを入力していると、5 分間が永遠のように感じられます。数千のノードのクラスターを小さなクラスターに分割すると、簡単に過負荷になってしまうため、サイトがいつでもダウンする可能性があることはわかっていました。

私はすぐに上司のデスクまで走って行き、状況を説明しました。彼はメールからほとんど目を離さなかったので、私はイライラしました。彼は顔を上げて微笑み、「ええ、マーケティング部門が広告キャンペーンを実施することもあります。そういうことは時々ありますよ」と言いました。彼は、Akamai からのトラフィックをオフロードするために、アプリケーションに特別なフラグを設定するように指示しました。私は急いでデスクに戻り、何千もの Web サーバーにフラグを設定しました。そして数分後、サイトは復旧しました。災害は回避された。

このようなストーリーをあと 50 件ほど共有することもできますが、おそらく皆さんの心の中には「この運営方法はどこに向かっているのか」という疑問があるでしょう。

要点は、私たちにはビジネス上の問題があったということです。技術的な問題によってビジネスが妨げられると、その問題はビジネス上の問題になります。つまり、Web サイトにアクセスできない場合、顧客の取引を処理することはできません。

それで、これらすべては Kubernetes とどのような関係があるのでしょうか?すべて！世界は変わった。 90 年代後半から 00 年代前半には、大規模な Web サイトだけが Web 規模の大きな問題を抱えていました。今日、マイクロサービスとデジタル変革により、あらゆる企業が大規模な問題に直面しています。大規模な問題が複数存在する可能性もあります。

企業では、多くの異なる人々によって構築された、多くの場合複雑な多数のサービスにわたる、複雑で大規模な Web サイトを管理できる必要があります。ウェブサイトはトラフィックを動的に処理する必要があり、安全でなければなりません。これらのプロパティは、インフラストラクチャからアプリケーション層まで、すべての層の API によって駆動される必要があります。

Kubernetesの登場

Kubernetes は複雑ではありません。あなたのビジネス上の問題は複雑です。アプリケーションを本番環境で実行する場合、パフォーマンス (スケーラビリティ、パフォーマンス ジッターなど) とセキュリティの要件を満たすために、最小限の複雑さが必要です。高可用性 (HA)、容量要件 (N+1、N+2、N+100)、最終的な一貫性を保証するデータ テクノロジなどが必要になります。これらは、Google、Facebook、Twitter などの大手サイトだけでなく、デジタル変革を進めているすべての企業にとっての生産要件です。

昔、私が American Greetings にいた頃は、新しいサービスを追加するたびに、すべて Web サイト運用チームが処理し、注文システムを通じて処理するために他のチームに引き継がれることはありませんでした。これは DevOps 以前の DevOps でした。

1. DNS を構成する (通常は内部サービス層と外部公開層)
2. ロードバランサーを構成する（通常は内部サービスとパブリック向け）
3. ファイルへの共有アクセスの構成 (大規模な NFS サーバー、クラスター化されたファイル システムなど)
4. クラスター ソフトウェア (データベース、サービス レイヤーなど) を構成する
5. Web サーバー クラスターを構成する (10 台または 50 台のサーバー)

構成のほとんどは構成管理によって自動的に行われますが、各システムとサービスにはまったく異なる形式の異なる構成ファイルがあるため、依然として複雑です。これを簡素化するために Augeas などのツールを検討しましたが、コンバーターを使用してさまざまな構成ファイルを標準化しようとするのはアンチパターンであると判断しました。

現在、Kubernetes を使用すると、新しいサービスを起動すると、基本的に次のようになります。

• Kubernetes YAML/JSON を構成します。
• Kubernetes API に送信します (kubectl create -f service.yaml)。

Kubernetes はサービスの起動と管理を大幅に簡素化します。サービス所有者 (システム管理者、開発者、アーキテクト) は、Kubernetes 形式の YAML/JSON ファイルを作成できます。 Kubernetes を使用すると、すべてのシステムとすべてのユーザーが同じ言語を話します。すべてのユーザーが同じ Git リポジトリにこれらのファイルをコミットできるため、GitOps が有効になります。

さらに、サービスは廃止され、削除される可能性があります。歴史的に、DNS エントリ、ロード バランサ エントリ、Web サーバー構成などを削除すると、何かが壊れてしまうことがほぼ確実であったため、非常に恐ろしいことでした。 Kubernetes ではすべてが名前空間化されているため、1 つのコマンドでサービス全体を削除できます。他のアプリケーションがそれを使用しないようにする必要はありますが (マイクロサービスと Functions as a Service [FaaS] の欠点)、サービスを削除してもインフラストラクチャ環境が混乱することはないという確信が持てます。

Kubernetesの構築、管理、使用

Kubernetes を使用するのではなく、構築と管理に重点を置いている人が多すぎます (Kubernetes はダンプ トラックですを参照)。

単一のノード上にシンプルな Kubernetes 環境を構築することは、LAMP スタックをインストールすることとそれほど複雑ではありませんが、構築するか購入するかについては延々と議論が続いています。 Kubernetes が難しいというわけではありません。高可用性を維持しながら、大規模なアプリケーションを実行します。この規模のクラスターを構築するのは困難であるのと同様に、複雑で可用性の高い Kubernetes クラスターを構築するのは困難です。計画と多くのソフトウェアが必要です。単純なダンプトラックを作るのはそれほど複雑ではありませんが、10 トンのゴミを運び、200 マイルの速度で安定して走行できるトラックを作るのは複雑です。

大規模なクラスターの管理が複雑になるのと同様に、Kubernetes の管理も複雑になる可能性があります。場合によっては、このインフラストラクチャを管理することが理にかなっています。時々そうならないこともあります。 Kubernetes はコミュニティ主導のオープンソース プロジェクトであるため、業界ではさまざまな方法で管理できます。プロバイダーはホスト型バージョンを販売でき、ユーザーはそれを自由に管理できます。 （しかし、それが本当に必要かどうかは疑問に思うべきです。）

Kubernetes を使用することは、大規模な Web サイトを実行するための最も簡単な方法です。 Kubernetes は、Linux が Web 1.0 で行ったように、大規模で複雑な一連の Web サービスを実行する機能を民主化します。

時間とお金はゼロサムゲームなので、Kubernetes の使用に重点を置くことをお勧めします。 Kubernetes プリミティブの習得や、生存性および準備状況のプローブを処理する最適な方法の習得に時間と費用をかけてください (大規模で複雑なサービスがいかに難しいかを示すもう 1 つの例)。 Kubernetes の構築と管理に重点を置かないでください。多くのベンダーが（構築と管理に関して）サポートしてくれます。

結論は

この投稿の冒頭で説明したような無数の問題をトラブルシューティングしたことを覚えています (当時の Linux カーネルの NFS、自社製の CFEngine、特定の Web サーバーでのみ発生するリダイレクトの問題など)。開発者はこれらの問題をすべて解決するのを手伝うことができませんでした。実際、開発者が高度なシステム管理者のスキルを持っていない限り、システムに入り込んで第二の目として支援することさえできない可能性が高いです。グラフや「可観測性」を備えたコンソールは存在しません。可観測性は私や他のシステム管理者の頭の中にあります。今日では、Kubernetes、Prometheus、Grafana などにより、すべてが変わりました。

鍵は次のとおりです。

時代は変わった。今日、すべての Web アプリケーションは大規模な分散システムです。 AmericanGreetings.com はかつては複雑でしたが、現在ではすべての Web サイトにスケーラビリティと HA の要件があります。

大規模な分散システムを実行するのは困難です。絶対に。これはビジネス要件であり、Kubernetes の問題ではありません。よりシンプルなオーケストレーション システムを使用するのは解決策ではありません。

Kubernetes は、複雑な Web アプリケーションのニーズを満たす最もシンプルで簡単な方法です。これが私たちが生きている時代であり、Kubernetes はその点で優れています。 Kubernetes を自分で構築または管理するべきかどうかについては議論の余地があります。構築と管理を支援できるベンダーは多数ありますが、これが複雑な Web アプリケーションを大規模に実行する最も簡単な方法であることは否定できません。