完全自動化されたKubernetes運用

PlayStation Network (PSN) は、多くのチームや世界中の拠点にまたがる膨大なサービスを運用しています。この多様性に対して一貫性を保つために、私たちはKubernetesを統一プラットフォームとして採用しました。しかし、PSNが運用している多様なサービスを管理することは、技術的・組織的にも私たちに大きな負担をかけていました。そこで、私たちはより効率的なアプローチが必要だと感じていました。

もし、Kubernetesクラスタ管理が自動化された世界があると想像してください。深夜のインシデント対応や手動での更新作業、突発的なトラブル対応はもう必要ありません。これがまるで夢物語のように聞こえるかもしれませんが、PSNプラットフォームではすでに現実のものとなっています。

急速に進化するクラウドネイティブの世界では、Kubernetesは瞬く間にコンテナオーケストレーションの標準となり、強力な機能を提供しています。しかし、その代償は「複雑さ」でした。従来、Kubernetesクラスタの管理には多くの手作業と高度な専門知識が必要でした。

しかし、もしこの複雑さをシンプルにできるとしたらどうでしょう？もし全てのプロセスが自動化され、開発者やSRE（Site Reliability Engineer）が本当に価値を生み出すことに集中できるようになるとしたら？ 私たちはまさにその変革を実現しました。PSNにおける完全自動化されたKubernetes運用の新時代へようこそ。今や、プラットフォームが自己管理し、チームは最も重要なことに集中できる環境が整っています。

課題: 複雑さとの闘い

私たちの旅は、シンプルでありながら深遠な問いから始まりました。それは、「Kubernetesを必要不可欠なものにしている柔軟性とパワーを維持しながら、より管理しやすくするにはどうすればよいか?」というものでした。多くの組織と同様に、私たちもいくつかの課題に直面しました。

• 一貫性のないInfrastructure as Code (IaC) 定義: 異なるチームが異なるツールを使用していたため、クラスタの構成やリソース割り当てに不一致が生じました。この一貫性の欠如により、管理対象が同期から外れ、不安定で予測不可能な状態になりました。
• 手動プロセス: 新しいKubernetesクラスタのセットアップは、手動による複数のステップを必要としました。VPC、サブネット、IAMロールの設定など、各ステップに手作業が必要であり、非効率な状態やエラー、遅延が発生しました。リソースのスケーリングも労力を要し、すべてを最新の状態に保つためには継続的な手動介入が必要でした。
• 限定的な自動化: 繰り返し発生するタスクが、貴重なエンジニアリングの時間を消費しオペレーションを停滞させていました。手動でのスケーリング、バックアップ、セキュリティパッチが一般的で、インフラが脆弱になり、チームが過労状態に陥っていました。
• 運用の複雑さ: 50を超えるKubernetesクラスタと各クラスタ上での50以上のアドオン管理、ネットワーキング、IAMロール、パフォーマンス最適化やセキュリティに至るまで、その手動かつ複雑な作業量は膨大なものでした。

問題の根本原因: なぜ複雑さが支配していたのか

私たちがさらに深く掘り下げていくと、以下の課題の根本原因が明らかになりました。

• カスタマイズの必要性: 地理的に分散した部署は、それぞれ独自に発展したネットワークやセキュリティ設計を持っていました。その結果、ネットワーク設計やセキュリティコントロールの展開方法が異なり、整合性が取れない状況が生まれていました。
• マルチチームの関与: これらのクラスタを管理するには、ネットワーク、セキュリティ、オブザーバビリティといった複数のチームの緊密な協力が必要でした。各変更には承認が必要であり、それがボトルネックやコミュニケーションミスにつながることが多々ありました。
• 手動による検証: 手動プロセスはエラーを招き、デプロイメントを遅らせていました。自動チェックがないため、基準が異なり、一貫性の欠如や潜在的な脆弱性が生じていました。
• 統一されたプロセスの欠如: 標準化されたツールやプラクティスがなかったため、各チームが独自の方法を採用しており、混乱と非効率が生まれていました。新しいチームメンバーのオンボーディングが遅くなり、問題解決にも時間がかかっていました。

転換点: 標準化と自動化の導入

複雑さに直面した私たちは、根本的な変革が必要だと認識しました。その答えは、標準化を進め、自動化を単なるツールとしてではなく、新たな運用哲学として受け入れることでした。

• ツールとプラクティスの標準化: 私たちはTerraformを統一されたIaCツールとして選定し、環境の標準化を進め、デプロイ時の予期せぬ事態を減らしました。テンプレート化されたプロセスを採用することで、クラスタの作成が迅速かつ一貫したものとなり、組織全体での効率化が図られました。また、ポリシーエンジンを導入してセキュリティ基準を強制し、PSNのセキュリティポリシーやPCI、SOXといった規制要件を満たすクラスタを展開しました。
• IaCとモニタリングの自動化: TerraformとカスタムスクリプトをGitOpsパイプラインに統合し、Kubernetesクラスタの作成と設定を自動化しました。モニタリングツールを実装し、問題を事前に検出してアラートを発し、手動介入の必要性を減らしました。これには、クラスタのアドオン、ワーカーノード、サブネットIP使用量のモニタリングが含まれ、トラフィックパターンに基づいた自動スケーリングが可能となりました。
• セルフサービスプロセス: チームに権限を持たせるために、セルフサービスツールを導入し、一般的なタスクを独自に処理できるようにしました。チームはIAMロールやコンテナイメージリポジトリの作成などを承認を待つことなく実行できるようになり、オンボーディングプロセスが加速しました。
• 自動検証: IaC設定やKubernetesクラスタのセットアップを自動的に検証しました。TerratestやSonobuoyなどのツールを使用して、インフラが正しくプロビジョニングされていること、重要なアドオンが適切に構成されていることを確認しました。モニタリングやログ設定も検証され、運用管理基準を満たしていることが保証されました。
• チーム間の協力の促進: クラスタ作成と検証プロセスにおける各チームの役割を明確にするために、RACI（責任、説明、協議、報告）構造を確立しました。このアプローチにより、何が承認を必要とするかの混乱が解消され、クラスタの提供が数週間から数時間へと劇的に短縮されました。

Kubernetesアドオンの混乱を制する

初期セットアップ: HelmとTerraform

Kubernetesアドオンの管理に最初に取り組んだ際、私たちはHelmをほとんどの設定に選び、各コンポーネントにTerraformモジュールを補完的に使用しました。このアプローチは、成長するKubernetesクラスタ群に一貫性を提供し、デプロイメントワークフローにもスムーズに適合しました。当初はすべて順調に進み、私たちは自分たちのセットアップに自信を持っていました。

成長の痛み: 問題の発生

しかし、クラスタが50を超え、50以上のアドオンをサポートするようになると、私たちは運用に支障をきたす問題に直面し始めました。

• 運用上のギャップ: クラスタが増えるにつれて、PRの競合やアドオン間の依存関係の管理が困難になりました。以前は管理可能だったものが、今では絶え間ない注視を必要とするようになりました。
• 断続的な障害: CoreDNSやVPC CNIなどの重要なアドオンが頻繁に障害を引き起こし、また曖昧で一般的なエラーメッセージによってデバッグが難航する事が多々ありました。
• 異なるチームによる管理: クラスタのアドオン管理は、セキュリティ、オブザーバビリティ、コスト管理など、さまざまなチームに分散されていました。この役割分担により、持続可能で協調的なデプロイメント戦略が必要であることが明らかになりました。

前進への道: 要件の特定

これらの課題に対処するため、私たちは強固なアドオン管理アプローチに必要な要件を定義しました。

• 分散デプロイメント: 複数のクラスタにアドオンを効率的に展開し、障害を引き起こさないシステム。
• 多様性へのサポート: 異なる構成を持つクラスタに対応し、信頼性を損なうことなく柔軟性を確保できるソリューション。
• 障害の軽減: スケーリングに伴うリスクを軽減しながら、デプロイメントの俊敏性を維持できること。

ソリューション: ArgoCDの導入

これらの要件を満たすために、私たちは宣言的で自動化されたアプローチを持つArgoCDをKubernetesのアドオン管理に採用しました。

• 宣言的デプロイメント: ArgoCDを使用することで、Helmチャートを宣言的にデプロイすることが可能になり、プロセスを効率化するだけでなく、Kubernetesワークロードの健全性を明確に可視化できました。
• アプリケーションセットコントローラー: ArgoCDのアプリケーションセットコントローラーを活用し、単一のマニフェストで複数のクラスタを管理することで、一貫性を確保しました。
• 分散型アプローチ: 組織内の異なるチーム向けに専用のArgoCDインスタンスとアプリケーションセットを実装し、競合を減らし、ワークロードをソースマニフェストと同期させ、より細かい制御が可能になりました。
• 独立した運用: 各チームが自分のアドオンを独自に管理できるようになり、明確な所有権と責任が生まれました。このアプローチにより、効率が向上し、依存関係が減少し、より迅速かつ信頼性の高いデプロイメントが可能になりました。

ArgoCD運用時に発生したインシデント： 重要なクラスタ・アドオン管理の教訓

• ArgoCDを用いてクラスタを運用する中で、ArgoCDとCoreDNSやVPC-CNIなどの重要なアドオンに関わる重大なインシデントに直面しました。この事象は定期的なアップデートプロセス中に該当アドオンが不注意に削除された事により発生し、循環依存によりクラスタ環境全体に影響を及ぼしました。
• また、管理の複雑さを軽減するために1つのマニフェストを通して複数のクラスタを管理するアプローチ取っていたことで状況はさらに複雑なものになりました。該当アドオンのマニフェストが誤って更新された際の影響範囲は大きく、複数のクラスタに影響を及ぼし、広範な混乱につながりました。詳細な検証を行った結果、根本的な原因は実装フェーズの初期に行われたいくつかの設計上の決定にあることが判明しました。
  
  具体的には、CoreDNS や VPC-CNI などの重要なクラスタ アドオンを ArgoCD で管理し、かつ複数のクラスタを単一のマニフェストに統合することで、最終的にシステムの安定性を損なう問題が発生しました。

インシデント後の改善

• このような課題を受けて、私たちはインフラの耐障害性を向上させるために早急に対策を講じました。まず、CoreDNSやVPC-CNIのような重要なアドオンの管理をArgoCDからTerraformに移行することにしました。これらの重要なコンポーネントをクラスタのInfrastructure-as-Code(IaC)運用により密接に結びつけることで、より安定した信頼性の高い環境を確立しました。この移行はシームレスに実行され、アプリケーションにダウンタイムを発生させることなく、Terraformが既存のリソースをコントロールしました。
• さらに、ArgoCD のアドオンマニフェストを分割し、各クラスタを独立して管理するようにしました。このアプローチにより、よりきめ細かい制御が可能になり、1つのクラスタでのエラーが他のクラスタに連鎖するのを防ぐことができます。複数のクラスタに対して重複したマニフェストを維持するオーバーヘッドを回避するために、自動化されたプログレッシブ デプロイメント フレームワークを実装しました。これにより、継続的デリバリのために ArgoCD のパワーを利用しながら、すべてのクラスタにわたってスムーズでエラーのないアドオン管理が保証されます。
• これらの改善により、アプリケーション インフラストラクチャに影響を与えることなく、すべてのクラスタにわたって移行を実行し、より信頼性の高い堅牢な運用環境を実現することができました。
• また、障害が発生した後の対策として、ディザスタリカバリ計画を策定しました。

ディザスタリカバリ計画の定義

ディザスタリカバリ計画の効果を最大化するため、以下の目標を設定しました。

• 復旧時間目標（RTO）: 業務要件とSLAに基づいて許容可能な最大ダウンタイムを定義し、ディザスタリカバリ計画が運用ニーズと一致するようにしました。
• 復旧ポイント目標（RPO）: 許容できる最大データ損失量を決定することで、バックアップの頻度を導き、保護とリソース効率のバランスを取りました。

ディザスタリカバリ計画の展開

定義されたRTOやRPOを元に、Veleroを用いてKubernetesクラスターのバックアップを定期的に実行するようセットアップしました。

自動化により得られた恩恵

完全に自動化されたKubernetesプラットフォームへの旅は、驚くべき結果をもたらしました：

一貫したIaCと効率性：統一されたIaCツールとしてTerraformを選択することで、環境を標準化しクラスタ作成の問題を大幅に削減しました。Cookie-cutterを利用したテンプレートの活用により、クラスタ作成にかかる時間を2～3週間からわずか4～5時間へと90%削減し、組織全体の一貫性を向上させました。自動化された検証によりIaCの精度が向上し、設定ミスが大幅に減少しました。

スケーラビリティと柔軟性：Kubernetesのネイティブな自動スケーリング機能を活用して、さまざまなトラフィック負荷に対応し、パフォーマンスとユーザーエクスペリエンスを維持しました。KEDA（Kubernetes Event-driven Autoscaling）を介した外部メトリクスにより、需要に基づいてサービスポッドを自動的にスケールさせることができました。リソースメトリクスに基づいてサービスポッドをスケールアップするためにエンジニアが手動で介入する必要がなくなり、その結果、ワーカーノードが自動的にスケールアップしてポッドのスケジューリングが行われるため、スケーラビリティが劇的に改善されました。

セキュリティとコンプライアンスの強化：Kyvernoのようなポリシーエンジン、および自動コンテナスキャンはセキュリティとネットワーク標準への継続的なコンプライアンスを維持するのに役立ちました。ディザスタリカバリ計画に基づき、プロセスを自動化することで、あらゆる災害後にバックアップからプラットフォームを確実に復旧できるようになり、RTOを90%削減できました。

開発者の生産性の向上：運用のオーバーヘッドが削減されたことで、開発者はコーディングとイノベーションにより集中できるようになりました。Kubernetes Jenkinsエージェントのプロビジョニング時間が短縮されたことで、迅速なデプロイと頻繁なリリースが可能になりました。デプロイパイプラインでKubernetesエージェントを使用し、エージェントのデプロイステージ間で再利用可能な設定を活用することで、EC2ベースのエージェントと比較しておよそ1分から数秒へ、デプロイ時間が70%短縮されました 。

未来への展望: この旅路を続ける為に

私たちは、今後も自動化の能力をさらに洗練し、拡大していくことにコミットしています。次のステップとして、より高度なスケールアップの統合、ディザスタリカバリ戦略の強化、Kubernetes上でのサービスメッシュの導入によるさらなる効率化とコスト削減に取り組んでいます。

Istioを使用したサービスメッシュの導入により、開発者がコードを変更することなく、mTLS認証、暗号化、ポリシーコントロール、オブザーバビリティ、そして高度なトラフィック管理などのアプリケーション機能を提供します。また、分散システムが堅牢でありながら、接続され保護され続けることを保証するために、マルチクラスター環境の確立にも取り組んでいます。

Karpenterは、Kubernetesネイティブのクラスタオートスケーラーであり、効率的なワーカーノード管理を提供します。Karpenterは、コスト効率の高いワーカーノードのEC2インスタンスを自動的にプロビジョニングし、ライフサイクル管理を完全に自動化することで、Kubernetesインフラストラクチャをシンプルにします。数ヶ月にわたる評価を経て、私たちのKubernetesプラットフォーム全体での導入が開始され、ワークロード管理の近代化が進行中です。

AWS Pod Identityは、Kubernetes上でアプリケーションIAM認証情報を管理する新しい方法です。IRSA（IAM Roles for Service Accounts）からの進化であるPod Identityは、大量のサービスをオンボーディングする際に発生するOIDCの制限を排除し、統一された信頼ポリシーモデルと詳細なアクセス制御を備えたKubernetesクラスタにおけるIAM権限管理を簡素化します。

完全自動化されたKubernetes運用への旅は続いていますが、これまでの成功は、自動化が単なる贅沢ではなく、現代のクラウドネイティブ環境をスケーリングし、持続可能にするために不可欠なものであることを証明しています。私たちはこれからも、可能性の限界に挑み続けることにワクワクしています。この旅路にぜひご参加いただき、PlayStationを最高の職場にするための取り組みに共に歩んでいきましょう。