Anthos

Banco BV が GKE と Anthos でバンキングアプリをモダナイズ

Thu, 13 Jul 2023 01:20:00 +0000

※この投稿は米国時間 2023 年 7 月 6 日に、Google Cloud blog に投稿されたものの抄訳です。

編集者注: 今日のゲスト投稿では、Anthos と Google Kubernetes Engine（GKE）を採用したアプリケーションのモダナイゼーションについて Banco BV にお話を伺いました。Banco BV は、データセンターの OpenShift プラットフォームから Google Cloud の GKE にバンキングアプリを移行し、Anthos Service Mesh と Config Sync を使用して、本番環境、開発環境、テスト環境のチーム全体で GKE クラスタを管理しています。Google Cloud への移行により、Banco BV はデジタルバンキングプラットフォームをスケールできるようになり、顧客向けアプリケーションの信頼性とスケーラビリティが大幅に向上しました。

ブラジル最大級の民間銀行の一つである Banco BV は、運営するあらゆる市場セグメントでお客様のニーズを満たす革新的なソリューションを提供しています。Banco BV は、より効果的に技術革新を推進するための変革とソリューションを常に模索しています。

Google Cloud と当行の協力関係は 2020 年に始まりました。この年は、当行がクラウド基盤の構築を開始し、それに基づいてチームを整備し、クラウドの活用を進めようとしていた時期でした。クラウドへの投資を最大限に活用することが重要であったことから、Google Cloud ソリューションに基づいた FinOps モデルを実装しました。クラウド FinOps のコンセプトは、テクノロジー、ファイナンス、ビジネスに基づいた運用フレームワークと文化の変革に関わるものです。その目標には、財務上の説明責任を促進し、ビジネス価値の創出を加速させることが含まれます。

Google Cloud への移行という Banco BV のデジタルトランスフォーメーションのさらなる一環として、当行は、運用費用の節約を目的として、セルフマネージドプラットフォームからフルマネージドサービスへのバンキングアプリケーションの移行を目指すことにしました。さらに重要なこととして、コンテナプラットフォームのスケーラビリティ、CI / CD パイプラインの効率性、アプリケーションモニタリングの可視性を向上させる必要がありました。

当行はまず、バンキングアプリケーションをデータセンターのセルフマネージド型 OpenShift ソリューションから GKE に移行することから始めました。移行プロセスには 3 か月ほどかかりました。Anthos Service Mesh（ASM）を有効にしたことで、段階を追って徐々に移行することができました（図 1 を参照）。

図 1: オンプレミスデータセンターから GKE へのアプリケーションの移行

当初、Kubernetes クラスタは環境ごとに 1 つだけでした。これらの環境の成長とさまざまなビジネスユニットの関心を考慮して、ビジネスユニットごとに個別のクラスタを備えた新しいアーキテクチャを設計し、分離とアクセス制御を強化しました。ただし、これらのアプリケーションを新しいクラスタに配布するのは困難でした。これを克服するために、開発者がデプロイ先のクラスタを選択できるオプションをセルフサービスポータルに作成しました。アプリケーションをあるクラスタから別のクラスタに移行する必要がある場合、ターゲットクラスタの Workload Identity をはじめとする構成が自動的に適用されます。

図 2: バンキングアプリケーションを実行するための GKE アーキテクチャの概観図

GKE は、自動化されたスケーラブルなコンテナプラットフォームを提供します。当行の開発者は、セルフサービスポータル経由でクラウドリソースをリクエストできます。クラウドリソースの作成は Terraform によって完全に自動化されており、当行のポリシー（セキュリティ、FinOps など）に準拠しています。GKE は、開発者の生産性を高めることを目的とした豊富な統合ツールも提供しているので、私たちは効率的な CI / CD パイプラインも確立できました。Anthos は、GKE クラスタの効率的な管理を支援します。また、GitOps 手法に沿って、名前空間の作成をはじめとするクラスタ構成に Anthos Config Sync を活用することで、運用のスケーラビリティ、監査可能性を確保し、バージョン管理を可能にしています。また、当行は、マイクロサービスベースのシステムアーキテクチャに Anthos Service Mesh を広範囲に使用しています。このサービスメッシュは、サービス間の安全な通信を促進するだけでなく、アプリケーションのパフォーマンス、可用性、可視性も向上させます。

Google Cloud に移行してからの 1 年で、ブラジル市場向けの即時送金サービスをはじめとするバンキングサービスのトランザクション数が 75 倍になるという驚異的な数字を記録しました。当行のクラウドエンジニアマネージャーである Ivan Gancev は、「新しいアーキテクチャは、信頼性とコンプライアンスの要件を確実に満たしながら、需要に合わせてスケールできます。GKE と Anthos の採用に非常に満足しています。システムの信頼性とスケーラビリティを維持しながら、より迅速にお客様の手に価値を提供できるようになりました」と話しています。

今日の消費者は、24 時間 365 日のデジタルエクスペリエンスを求めています。当行はインフラストラクチャの運用方法を改善できる新しい方法を模索し続けています。2022 年の中期から後期にかけて、Anthos Service Mesh で新しい「マネージドコントロールプレーン」機能を採用しました。これは当行にとって大きな変革となりました。私たちは、サービスメッシュの更新とアップグレードを Google SRE チームに任せ、ビジネスの優先事項により集中できるようになりました。さらに、セキュリティとコンプライアンスを一元管理できる Anthos Policy Controller の検討も行っています。特に、ベストプラクティスの適用、業界標準への準拠、GKE クラスタ全体にわたる規制問題の解決に役立つすぐに使えるポリシーバンドルに好印象をもっています。

GKE を採用し、マルチクラスタ管理に Anthos を使用することで、効率的でスケーラブルかつ信頼性の高い最先端のコンテナ管理プラットフォームでアプリケーションを実行できます。これにより、お客様にご満足いただける素晴らしいバンキングサービスを提供することができるはずです。

Google Cloud のウェブサイトにアクセスして、GKE と Anthos がもたらすメリットをご確認ください。また、詳細なチュートリアルに沿って操作することで、今すぐ利用を開始できます。

- Banco BV、クラウドエンジニア Daniel Azevedo 氏
- Banco BV、クラウドエンジニアコーディネーター Rodrigo Moreno 氏

aside_block: <ListValue: []>

スマートシティチューリッヒ: 都市のデジタルトランスフォーメーションを推進している Anthos の舞台裏

Wed, 12 Jul 2023 03:00:00 +0000

※この投稿は米国時間 2023 年 7 月 5 日に、Google Cloud blog に投稿されたものの抄訳です。

自治体の IT 部門は都市のデジタルトランスフォーメーションをどのようにサポートできるでしょうか。チューリッヒの情報技術センター OIZ の主任 IT アーキテクトである Reto Hirt 氏にたずねます。今回のゲストブログ投稿では、チューリッヒ市のデジタル化の加速をサポートしている Hirt 氏の部門の舞台裏をご紹介します。公共部門における IT 特有の課題、チューリッヒの IT 部門が Anthos を使用してクラウドテクノロジーのメリットをどのように市のオンプレミスアプリケーションにもたらしているか、それによってハイブリッドクラウドアプローチがどのように実現されているかについて Hirt 氏にお話しいただきました。

チューリッヒは、湖畔の景観、高山の静けさ、生活の質の高さで知られています。また、ヨーロッパにおける金融の中心地の一つであり、世界で最もスマート化の進んでいる都市のリストに常に挙げられています。最も重要なことは、機能する病院、公共交通機関、その他日常生活に必要な多くの施設や設備を必要とする 44 万人以上の住民がチューリッヒで暮らしていることです。約 3 万人の職員と 600 人の IT スペシャリストが、市のサービスを稼働し続けるために 24 時間体制で精力的に働いており、チューリッヒのデジタル化および情報技術センターである OIZ にすべての部門が接続されています。

OIZ は 2,100 を超えるアプリケーションを担当しているため、そのサービスはなんらかの形ですべての住民の生活に影響を与えています。たとえば、「Mein Konto」ウェブプラットフォームを使用すると、チューリッヒ市民は 1 回のログインでさまざまなオンラインサービスに一元的にアクセスできます。こうしたサービスは、税金の支払い、市営アパートの賃貸、保育所の検索など、多くのことに役立ちます。私たちはこれらのサービスのユーザーエクスペリエンスをモダナイズする方法を常に模索していますが、すべてのアプリケーションを手動でスケールするためのリソースがありません。通常の企業であれば、すべてをクラウドに移行するだけで済むかもしれませんが、公共サービスとしてのデータ保護には、より慎重なアプローチが求められます。そうした経緯から、私たちは Anthos に注目しました。

ハイブリッドおよびマルチクラウドの将来に向けた市の基盤づくり

なぜ Anthos を選んだのかというと、ワークロードを実際にクラウドに移行することなく、最適な場所でワークロードをホストし、クラウドのメリットをオンプレミスのアプリケーションに適用できるという柔軟性を手にできるからです。また、特定のベンダーに対する依存度も軽減できます。Anthos があれば、コンテナ化されたアプリケーションを書き直すことなく、クラウド間の自由な移動を簡素化することができます。これは、マルチクラウド戦略に沿った中期計画にとってきわめて重要な点です。

スイスの大手 IT プロバイダでありクラウドスペシャリストである ti&m AG のサポートを受けながら、私たちは Anthos を活用して、自治体のオンプレミスデータセンターで必要に応じてアプリケーションを実行およびスケールできる新しいコンテナ管理プラットフォーム（CMP）を構築しました。CMP は、純粋にオンプレミスで実行されるデリバリープラットフォームと、必要に応じて将来的にクラウドに拡張できるランタイムプラットフォームの 2 つの部分で構成されています。Anthos を活用したこれらの CMP ソリューションを組み合わせることで、チューリッヒのアプリケーション環境の管理とセルフサービス方式での新しいアプリケーションのインテグレーションがはるかに容易になります。これは、組織内のチームにとっても、外部ソフトウェアプロバイダとのコラボレーションにとっても、真の変革をもたらすものです。

イノベーションに向けて都市をオープンに

外部ベンダーについていえば、私たちの新しいデリバリープラットフォームは、「セキュリティを犠牲にすることなく、ソフトウェアサプライヤーにチューリッヒ市向けのアプリケーションを構築してもらうにはどうすればよいか？」という根本的な問題を解決します。私たちは以前、特定のテクノロジーによる制限を受けていました。ベンダーがその範囲外のソフトウェアソリューションを提示してきた場合、私たちは拒否するか、動作させられるようにカスタムソリューションを使用しなければなりませんでした。

Anthos を使用すれば、作業がはるかに容易になります。外部のソフトウェアベンダーは、独自のレジストリを使用した独自の環境でアプリケーションを構築し、基盤となるインフラストラクチャ向けに書き直すことなく、自治体の CMP ソリューションに転送するだけで済みます。最初に稼働したアプリケーションの一つは、外部のソフトウェアサプライヤーによって構築されたチューリッヒの賃貸向けテナントポータルです。ベンダーはコンテナ内でアプリを構築し、それを自治体の環境に移動するだけでよいため、テクノロジーの違いはまったく問題になりませんでした。

これは私たちとベンダーの双方にメリットがあります。私たちはまったく新しいアプリケーションとソリューションを簡単に統合でき、それがチューリッヒとその住民に利益をもたらしています。また、ベンダーはそのシンプルさに感銘を受けています。

職員にセルフサービスと API 管理を提供する

もちろん、チューリッヒ市の職員も同じセルフサービスの機会を活用できます。Anthos を使用すれば、職員はアプリ開発ツールと配信ツールにアクセスできるようになり、継続的インテグレーションおよび継続的デリバリー（CICD）環境で新規のコードをユーザーに迅速に push することがはるかに容易になります。このプラットフォームは非常に使いやすいため、さまざまなレベルの経験をもつプログラマーが新しいアプリケーションを簡単に開発し、市全体に提供することができます。私たちの職員の中には、修士論文の一環として紙ベースの財務修正プロセスをデジタル化することに決め、いくらかのトレーニング後、すぐにアプリケーションを開発できた者がいます。

私たちのアプリケーション環境は着実に拡張を続けており、API は私たちのサービスを結び付ける接着剤として機能しています。私たちは 20 年以上 API を使用してきましたが、API にアクセスする標準化された方法がありませんでした。特定のサービスについて職員が疑問をもった場合、API のオーナーに電話して自分で解決する必要がありました。新しい API 管理ツールである Apigee は、一貫したフレームワークの作成に役立ち、職員はどの API をどのように使用できるかをすぐに確認することができます。

チューリッヒのモダナイゼーション - 一度に 1 つのサービス

私たちの新しい CMP は順調なスタートを切っています。これまでに 50 以上のアプリケーションを統合しており、今後はさらに数百ものアプリケーションを統合予定です。新しいアプリケーションをより迅速に構築、導入し、既存のアプリケーションをより適切にスケールできます。これは OIZ と市の IT チームにとっての素晴らしい成果ですが、最も重要なのは、市のサービスを日常的に利用しているチューリッヒの住民が生活しやすくなっていることです。スケーリングの改善によりサービスの停止が減り、多数のオンラインサービスが継続的に改良され、IT 部門が住民のニーズやフィードバックによりよく対応できるようになったことで、現在および将来の世代に向けてチューリッヒを変革する準備が整いました。

将来的には、さらに多くのワークフローをクラウドに移行する可能性がありますが、Anthos のおかげで急ぐ必要はなくなりました。Anthos は私たちにとって決して暫定的なソリューションではなく、アクセラレータともいえるものでした。安全なワークロードをすぐにクラウドに配置する必要はなく、クラウドテクノロジーの力を活用してアプリケーションをモダナイズできるからです。

- OIZ Zurich、主任 IT アーキテクト Reto Hirt 氏

AbemaTV：Google Cloud の活用による徹底した負荷対策によって世界的スポーツイベントにおいて安定した視聴体験を提供

Thu, 08 Jun 2023 00:00:00 +0000

株式会社AbemaTV（以下、AbemaTV）が運営する "新しい未来のテレビ"「ABEMA」では、サービス開始当初よりバックエンドシステムの構築に Google Cloud を採用しています。過去最大の WAU（週間アクティブユーザー数）を記録した世界的スポーツイベントの⁠全試合無料生中継で安定した配信を実現した背景について、負荷対策を担当したお二人にお話を伺いました。

利用しているサービス:

Anthos Service Mesh, Google Kubernetes Engine, Cloud Bigtable, Cloud Run, Pub/Sub, Cloud Trace

高トラフィックに対応するためにシステム構成の見直しを実施、Google Cloud の性能をフル活用へ

AbemaTV では、2015 年のサービススタート当初より、API やデータ分析、レコメンドシステム、広告配信といった周辺サービスの基盤として Google Cloud を利用しています。ABEMA のサービスが大規模になることを想定して、そのトラフィックに対応できる基盤が必要であったことや、大規模でも高速な開発サイクルを実現できることなどから、当時の大手クラウドサービスでは唯一 Kubernetes のマネージドサービスを提供していた GKE（Google Kubernetes Engine）を採用したと開発本部 SRE 海野嘉和氏は語ります。

「当時はまだコンテナオーケストレーションの導入事例そのものがあまり多くは無かったのですが、通常の VM ベースの開発に比べると、コンテナを利用した開発は圧倒的に開発速度が速かったという実感があります。実際にサービスが拡大した現在でも、マイクロサービスがどんどん増えて管理が複雑になってくるのを見ると、当時 GKE を選択したのは間違いではなかったと実感しています。マイクロサービスでよく課題になるネットワークの複雑性についても、Anthos Service Mesh を導入したことである程度は解消できているので、大きな問題にはなっていません。」

今回のスポーツイベントの中継でも基本的なアーキテクチャは既存のものが利用できるものの、急激なトラフィックの変化に備えてこれまで積み重なった技術的負債を解消することも必要だったと、開発本部プロダクト開発テックリード辻純平氏は説明します。

「今回は過去に無い規模のトラフィックが予想されたので、従来から抱えていた技術的な課題を解消して、Google Cloud の性能をフル活用できる形に改修しながら負荷対策を進めていく必要がありました。例えば Bigtable に関しては、データ整合性を重視してシングルゾーンで運用していたものを、アプリプロファイルを活用して整合性を維持しつつマルチゾーン構成に変更しました。インメモリデータストアに関しても、もともとは Redis Cluster をセルフホスティングで運用していたのですが、高負荷でのレイテンシー対策としてマイクロサービスごとに分割するように構成し直しています。MongoDB も同様にマイクロサービス単位での分割を行いました。また、それまで台湾リージョンで運用していたのですが、レイテンシーなども考慮して今回の機会に東京リージョンへの移設も行っています。」

当日に起こりうる問題を洗い出すために、PSO チームと連携して徹底した事前対策を実施

実際の試合当日におけるトラフィックは ABEMA にとって過去最大のものとなりましたが、結果的に全試合大きなトラブル無く安定した配信を行うことができました。その成功の背景には、前述のシステム改修と並んで、Google Cloud の Professional Services Organization（PSO）チームと連携して行った徹底した事前対策がありました。

「当日に向けた負荷対策として最初に行ったのが、トラフィックの見積もりと、我々がクリティカルユーザージャーニーと呼んでいた "絶対に停止させてはいけない部分" の特定です。トラフィックについては、まず直前に開催された大規模な格闘技イベントの配信からアクセスログを分析し、それを参考にしてリクエスト数の見積もりを行いました。この見積もりはあくまでもテストシナリオ作成の参考にするための大ざっぱなもので、予測したトラフィックを基にして十分に大きな負荷で試験を行い、クリティカルユーザージャーニーが落ちないように対策していく、というのが全体の大きな流れです。」（海野氏）

テストシナリオの作成にあたっては、試合中に起こり得る出来事とそれに対するユーザーの行動のモデル化を行いました。これは、リアルタイムに変動するアクセスに対してシステム側にどのような現象が起こるのかをシミュレートし、問題を洗い出すためのものです。

「実際の中継では、試合の展開に合わせて刻一刻とトラフィックが変動します。例えば試合開始直後やハーフタイム、ゴールが決まったときなど、さまざまな状況でのユーザーの行動を想定してシナリオを作り、それに基づいてクリティカルユーザージャーニーの負荷対策や、トラフィックのスパイクへの対策などを考えました。」（海野氏）

PSO チームからは、キャパシティプランニングにあたってのアドバイスや、負荷試験のレビュー、障害試験の提案などといった支援を受けることで、負荷対策の確実性が大幅に向上したと海野氏は語ります。

「社内のチームだけではどうしてもさまざまなバイアスがかかって工程の取りこぼしや優先順位付けの誤りなどが起こりがちになるため、PSO チームから率直なアドバイスをもらえたことは非常に助かりました。我々の負荷対策のアプローチに誤りが無いかといったことをはじめとして、Google Cloud の内部的なコンポーネントの特性を考慮した問題点の洗い出しなど、プロダクトの中身を知る専門家ならではの視点で確認してもらいました。」（海野氏）

負荷試験には Kubernetes で動作する負荷テストツールの k6 を使用し、クリティカルユーザージャーニーに至るさまざまな API のシーケンスコールをテストシナリオに基づいて再現。段階的にクライアント数を増やしながら問題が発生したら対策を施すというサイクルを繰り返して、最終的にビジネス目標とされていた同時視聴者数を達成しました。具体的には、データベースのスケールアウトやサーキットブレーカーの追加、Kubernetes ノードの増強、必要なリソースの追加などの対策を行ったとのことです。

障害試験では、特にリスクが高いコンポーネントが停止したり、外部サービスとの連携が遮断された場合などに、その影響範囲やシステム全体の挙動がどのように変わるかなどを確認しました。障害試験の組み立て方や、意図的に障害の状態を作り出す方法などについては、PSO チームのアドバイスが非常に役に立ったと辻氏は語ります。

「クラウドを意図的に壊すことは原理的にできないので、どのようにして障害の状況をシミュレートするかという問題がありました。その点について、PSO チームからは各サービスの特性を考慮した上で、仮想的に障害の挙動を発生させる方法などをアドバイスしてもらいました。クラウド内部の特性を含めた知見を共有してもらえたことには大きな価値がありました。」（辻氏）

今回の負荷対策に向けた改修項目のひとつに、分散トレースシステムである Cloud Trace の全面的な導入がありました。この Cloud Trace が、負荷試験や障害試験において発生した問題の分析に非常に役立ったと辻氏は語ります。

「マイクロサービスではどうしてもどこで問題が発生しているのかを特定しにくいという特性があるのですが、Cloud Trace を導入したことで細部のテレメトリーまで正確に把握できるようになったので、問題の特定にかかる時間を大幅に削減できました。試験中に明らかになった問題の中には、Cloud Trace が無ければ発見できなかったような性質のものもあります。今回の負荷試験は複合的な機能に着眼したものだったので、障害も連鎖的に発生するため非常に分析が難しいという特徴があり、分散トレースの仕組みが本当に役に立ちました。」（辻氏）

負荷試験・障害試験を最小限の手間で実施できるようにプラットフォームの改善を進めていく

これらの事前対策の成果により、大会中の配信では大きなトラブルは発生せず、始終安定して中継を届けることができました。実際には、想定していた最大同時接続数を上回るリクエストが発生した時間帯もあったものの、結果的に全試合に対して完全な機能を提供することができたと海野氏は語ります。

「同時接続数に対しては、目標最大数の半分までのリクエストに対しては確実に全機能を提供する、それを超えた場合でも最大数まではクリティカルな機能を維持して配信を継続するという要件を設定していました。結果的に、ピーク時には最大数に近い同時接続数を記録したのですが、システムは想定以上に安定しており、全機能の提供を継続することができました。これは、PSO チームの協力の下で事前に各種ボトルネックを解消できた成果だと考えています。」（海野氏）

この成功を踏まえて、同様の水準での負荷試験や障害試験を継続的に行えるようにプラットフォームの改善を進めていきたいと、辻氏は次のように語ります。

「今回の経験で、疎結合なマイクロサービスの複合的な試験は非常に手間がかかり、認知負荷も高いことを実感しました。この負担を取り除いて、負荷試験や障害試験を最小限の手間で継続的に実施できるプラットフォームを構築していく必要があると考えています。」

株式会社AbemaTV

2015 年 4 月、株式会社サイバーエージェントと株式会社テレビ朝日によって共同で設立。テレビのイノベーションを目指し "新しい未来のテレビ" として「ABEMA」を運営。登録は不要で、国内唯一の 24 時間編成のニュース専門チャンネルをはじめ、オリジナルのドラマや恋愛番組、アニメ、スポーツなど、多彩なジャンルの約 25 チャンネルを 24 時間 365 日放送している。

インタビュイー（写真左から）

株式会社AbemaTV

開発本部 SRE 海野嘉和氏
開発本部プロダクト開発テックリード辻純平氏

この記事の導入事例 PDF はこちらをご覧ください。

その他の導入事例はこちらをご覧ください。

Policy Controller ダッシュボード: Anthos と GKE のすべての環境で利用可能に

Wed, 24 May 2023 09:40:00 +0000

※この投稿は米国時間 2023 年 5 月 17 日に、Google Cloud blog に投稿されたものの抄訳です。

Kubernetes を大規模に利用しているお客様は、セキュリティ、リソース管理、柔軟性を向上させ、製品化までの時間の短縮と運用効率の向上を達成するために、環境全体のリソース使用状況について一貫したガードレールを必要とされています。

また、クラスタのフリートに対する適用ステータス、違反、修正の推奨事項など、ポリシーガードレールを簡単に適用、表示できる方法も求められています。そこで Google は 2023 年 1 月、すぐに使えるポリシーバンドルが付属した Policy Controller ダッシュボードをリリースしました。そしてこのたび、Policy Controller ダッシュボードをすべての Google Kubernetes Engine（GKE）と Anthos 環境（オンプレミス、マルチクラウド、接続クラスタ）でご利用いただけるようになりました。このダッシュボードでは、違反の修正に役立つ優れたフローが利用できます。

Policy Controller を使用すると、ガードレールとして機能する完全にプログラム可能なポリシーをクラスタリソースに適用し、セキュリティ、運用、またはコンプライアンスの管理に違反する変更を防止できます。Policy Controller は、デベロッパーが迅速かつ安全にコードをリリースできるようにすることで、アプリケーションのモダナイゼーションへの取り組みを加速させます。Policy Controller で監査、適用できるポリシーの例をいくつか以下にご紹介します。

すべてのコンテナイメージは承認されたリポジトリから取得する必要がある
すべての Ingress ホスト名はグローバルに一意である必要がある
すべての Pod にはリソース制限が必要である
すべての名前空間には、連絡先を一覧表示したラベルが必要である
クラスタのフリートで実行されているリソースは CIS Kubernetes Benchmark に準拠している必要がある
クラスタのフリートで実行されているリソースは PCI DSS ベンチマークに準拠している必要がある

Policy Controller ダッシュボード

一方、プラットフォームとセキュリティ管理者は Policy Controller ダッシュボードを使用して、次のことができます。

適用ステータス（dryrun、warn、enforced）など、クラスタのフリートに適用されたすべてのポリシーの状態を一目で確認
各違反に対する独自の推奨事項を参照することで、ポリシー違反を容易にトラブルシューティングして解決
クラスタリソースのコンプライアンスステータスを可視化

Policy Controller ダッシュボードは、ユーザーフレンドリーで直感的に操作できるよう設計されているため、あらゆるスキルレベルのユーザーがクラスタのフリートに対する違反を簡単に管理、モニタリングできます。これにより、ポリシー違反の状況を一元的に把握し、必要に応じて対処することが可能になります。

上のダッシュボードの円形グラフには、Policy Controller のインストール全般のステータス、違反しているクラスタ、クラスタのフリート全体に適用されているポリシーの合計など、すべての環境にわたるポリシーの状態が表示されます。違反措置は、ポリシーに照らしてリソースを監査しているだけなのか、クラスタの承認時にポリシーを適用しているのかを示します。

Policy Controller ダッシュボードページの下部には、フリートのポリシーバンドルごとのカバレッジが示され、該当バンドルに準拠しているリソースや違反しているリソースの割合が分けて表示されます。

棒グラフが完全にグレー表示されている場合、このクラスタのフリートにバンドルは適用されていません。棒グラフの一部がグレー表示されている場合、フリート内の 1 つ以上のクラスタにバンドルが適用されていません。
バンドルが 1 つ以上適用されている場合、リソースの全体的なコンプライアンスはバンドルに対して計算されます。棒グラフの青色の部分はポリシーに準拠しているリソースを示し、オレンジ色の部分は違反を表します。

各バンドルの違反リンクをクリックすると、下の画像に示されている詳細な [違反] タブが表示されます。

新しい [違反] タブを使うと、ご利用の環境でポリシー違反を簡単に表示して把握できます。

[違反] タブでは、クラスタ、バンドル、リソースの種類などに基づいて違反をフィルタできます。さらに、制約と名前空間ごとに違反をグループ化して、さまざまなユーザーペルソナがジョブの実行を効率化できるようになりました。いずれかのグループの制約リンクをユーザーがクリックすると、以下のように [制約] ビューが表示されます。

[制約の詳細] タブには、修正の対応案と制約 YAML が表示されます。

[制約の詳細] タブには制約の説明が表示されます。また、推奨される対応も示されるため、制約および影響を受けるリソースに対する違反を修正できます。クラスタ上に存在する制約の YAML を表示することもできます。[影響を受けるリソース] タブには、制約に違反しているすべてのリソースと詳細なエラーメッセージが下の図のように一覧表示されます。

[影響を受けるリソース] タブに、違反しているリソースが表示されています。

今すぐ使用を開始する

Google は使いやすさ、すぐに使えるコンテンツ、Google Cloud 機能のさらなる統合に重点を置いて、GKE と Anthos のフルマネージドポリシー機能の構築に投資を続けています。Policy Controller の使用を開始するには、Policy Controller をインストールし、CIS Kubernetes Benchmark などの基準に照らしてクラスタのフリートを監査するためにポリシーバンドルを適用してみてください。また、Policy Essentials バンドルに照らしてクラスタを監査するために、Policy Controller をご試用いただけます。Policy Controller の最新機能については、次回のブログ投稿で詳しくご紹介します。ぜひ Next ’23 に参加して詳細をご確認ください。

- Google Cloud、プロダクトマネージャー Poonam Lamba

Anthos ハイブリッド環境のリファレンスアーキテクチャを発表

Fri, 12 May 2023 03:00:00 +0000

※この投稿は米国時間 2023 年 4 月 29 日に、Google Cloud blog に投稿されたものの抄訳です。

セキュリティ体制を強化し、アプリケーションの信頼性を向上させ、環境内の構成のばらつきを減らす、新しい Anthos リファレンスアーキテクチャのリリースをお知らせします。

この新しいリファレンスアーキテクチャは、Google のプロダクト、エンジニアリング、サポート、フィールドの各チームの協力によって作成されたもので、Anthos ハイブリッド環境に必要なコンポーネントの計画、デプロイ、構成に役立ちます。

Anthos ハイブリッド環境では、Anthos clusters on VMware や Anthos clusters on bare metal を使用してコンテナベースのワークロードや VM を実行するオンプレミスのコンポーネントを柔軟にデプロイできます。オンプレミスのインフラストラクチャへの既存投資を引き続き活用しつつ、Anthos Config Management などのコンポーネントの追加を開始できます。すべてをまとめる準備ができたら、Artifact Registry、Cloud Monitoring、Identity and Access Management（IAM）などの Google Cloud ベースのサービスを追加できます。

ここでは、Anthos ハイブリッド環境を設計するためのベストプラクティスの一部を取り上げます。より詳細なガイダンスとプランニング情報については、完全な Anthos ハイブリッド環境のリファレンスアーキテクチャをご覧ください。

Anthos ハイブリッド環境を設計してデプロイする場合、2 つ以上のお客様が運用するオンプレミスコンピューティング設備と、2 つ以上の Google Cloud リージョンを使用し、オンプレミス設備では複数のクラスタを実行することをおすすめします。このアプローチは、以下のような理由で推奨されています。

障害復旧: 1 つのクラスタや設備で障害が発生しても、ワークロードを引き続き実行できます。
複数の環境: 本番やステージングといった複数の環境で、インフラストラクチャの変更をテストできます。
環境ごとに異なるクラスタタイプ: 管理者クラスタやユーザークラスタなどを用意します。このアプローチでは管理リソースが分離されるため、セキュリティのベストプラクティスに沿っています。

次の図は、複数のお客様が運用する設備とリージョンにまたがる Anthos ハイブリッド環境の例を示したもので、管理者とユーザーのワークロード用、および本番環境とステージング環境用に異なるクラスタを使用しています。

各設備では、Anthos clusters on VMware または Anthos clusters on bare metal を使用できます。両プロダクトとも、以下の使用方法をおすすめします。

3 台からなる高可用性（HA）コントロールプレーンを使用することで、オペレーティングシステムのアップグレード、コントロールプレーンソフトウェアのアップデート、単一マシンのハードウェアやカーネルの障害に際して同時実行を可能にし、コントロールプレーンの可用性を維持する。
管理クラスタを 2 つデプロイし、管理クラスタの設定変更やアップデートをステージング環境で最初にテストできるようにする。

次の図は、コントロールプレーンとワーカーノードが複数の物理マシンに分散している Anthos clusters on bare metal の例です。Anthos clusters on VMware では、コントロールプレーンとワーカーノードが複数の VMware VM に分散されています。

分析やレビューを行うため、ロギングとモニタリングのデータを Google Cloud に送信するようオンプレミスクラスタとアプリケーションを構成します。さまざまなペルソナに応じて、必要な環境へのアクセス権のみを付与します。次の図は、アプリケーションのデベロッパーや、アプリケーションやプラットフォームのオペレーターが、Google Cloud でロギングとモニタリングのデータを表示する方法を示しています。

Anthos Config Management を使用してクラスタ内の Kubernetes オブジェクトを管理します。Anthos Config Management は GitOps スタイルのツールで、Git リポジトリや Open Container Initiative（OCI）をストレージメカニズムおよび信頼できるデータソースとして使用します。Git プロバイダのワークフローでは、複数のステークホルダーが変更のレビューに参加できます。

次の図に示すように、一般的な Anthos Config Management のデプロイメントでは、1 つのフォルダにすべてのクラスタの構成が含まれます。アプリケーション用には個別のフォルダを追加して、構成データを保持します。

Anthos ハイブリッド環境でネットワークトラフィックを保護する方法を計画して実装します。クラスタ内の認証、接続、通信には以下のサービスが役立ちます。

Anthos Identity Service: クラスタをオンサイトの ID プロバイダに接続してローカルアクセスを認証します。
Connect ゲートウェイ: Workforce Identity 連携とともに、VPN を使用せずにモバイルワーカー用クラスタへのクラウドを介した安全なアクセスを提供します。
Workload Identity: オンプレミスのワークロードに管理された有効期間が短い認証情報を提供し、クラウドリソースへのアクセスを可能にします。
Anthos Service Mesh: 同じクラスタ内のサービス間の通信を暗号化して制御します。

次の図は、Anthos Service Mesh がクラスタ内のサービス間のトラフィックフローを制御する方法を示しています。

最初のオンプレミスのデプロイの一環として、これらのクラウドベースのサービスすべてを実装する必要はありません。使い慣れていくにつれ、こうしたハイブリッドサービスを追加し、機能拡張を図ることができます。しかし、このブログ投稿がヒントとなり、お客様の Anthos ハイブリッド環境の計画や設計を開始する際にお役に立てることを願っています。

より詳細なガイダンスとプランニング情報については、完全な Anthos ハイブリッド環境のリファレンスアーキテクチャをご覧ください。ご意見やご感想をお待ちしております。

- プリンシパルエンジニア Eric Tune
- プリンシパルエンジニア Dawn Chen

PSP のポリシーからポリシーバンドルへの移行

Fri, 28 Apr 2023 03:00:00 +0000

※この投稿は米国時間 2023 年 4 月 20 日に、Google Cloud blog に投稿されたものの抄訳です。

多くの組織が Pod Security Policy（PSP）を利用して Kubernetes の Pod に制限を適用しています。Kubernetes v1.25 での PSP の廃止を受け、セキュリティ体制を維持するために PSP と同等のポリシーが必要であるというフィードバックがユーザーから寄せられています。Pod Security Standards に移行する場合も PSP のポリシーの継続性を維持する場合も、Policy Controller によってビジネス目標を達成できます。

Policy Controller には、PSP の移行以外にも複数の機能があります。たとえば、あらゆる環境にあるクラスタのフリート全体のポリシー違反と修正のための推奨事項を表示する一元的なダッシュボードや、複数の適用ポイント（CI / CD、アドミッション、監査）および複数の適用タイプ（dryrun、deny）で必要なガバナンスとコンプライアンスに対応するために Google が構築、管理しているポリシーコンテンツなどです。

Policy Controller 以外の PSP 移行手段

Policy Controller への移行以外では、Pod Security アドミッション（PSA）コントローラやオープンソースの Gatekeeper などを使用する方法があります。

Policy Controller を使用した PSP の移行

既存の PSP は主に検証用のアドミッションコントローラであるとみなされることが多いのですが、PSP の構成によっては、ミューテーションアドミッションコントロールも含まれることがあります。今回の投稿では、まず Pod Security Policy（PSP）v2022 のポリシーバンドルを使用した PSP の検証機能の移行について解説し、続けて PSP ミューテーション移行の 2 つの主なオプションを取り上げます。

PSP の検証機能の移行

PSP バンドルは、Pod Security Policy の監査または適用を支援する制約のグループです。PSP バンドルをクラスタにインストールする場合は、Policy Controller v1.11.1 以上を使用します。含まれているポリシーは、デフォルトでは「監査」モードで構成されているので、既存または新しいワークロードに影響しません。これらのポリシーを適用するには、kubectl（後述）、kpt、または Config Sync を使用します。

1. 手順を開始する前に PSP バンドルの設定を完了し、カスタマイズした PSP バンドル用の新しいフォルダを作成します（例: org-restricted-psp）。

2. Pod Security Policy（PSP）v2022 のポリシーバンドルを取得します。たとえば、以下のように git を使用します。

code_block: <ListValue: [StructValue([('code', 'git clone https://github.com/GoogleCloudPlatform/acm-policy-controller-library.git\r\ncd acm-policy-controller-library/bundles/psp-v2022'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fee6e0bd040>)])]>

3. PSP バンドルの対応表を使用して、既存の PSP のフィールドに一致する関連制約を構成します。

たとえば、PSP「restricted」には「allowPrivilegeEscalation: false」が含まれています。この動作を構成するには、psp-allow-privilege-escalation-container.yaml の制約を org-restricted-psp フォルダにコピーします。

制約の中には、フィールド名の値に基づいたカスタマイズが必要なものもあります。たとえば、PSP「restricted」には「requiredDropCapabilities: [“ALL”]」が含まれています。この動作を構成するには、psp-capabilities.yaml の制約を org-restricted-psp フォルダにコピーし、allowedCapabilities パラメータを削除して、requiredDropCapabilities パラメータを [“ALL”] に設定します。

注: マッピングされた PSP フィールド名が既存の PSP に含まれていないフォルダには制約をコピーしないでください。

4. kubectl を使用して、カスタマイズしたポリシー制約を適用します。

code_block: <ListValue: [StructValue([('code', 'kubectl apply -f org-restricted-psp'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fee6e0bd5e0>)])]>

5. ポリシーの制約がインストールされていることを確認し、クラスタ全体で違反の存在を確認します。

code_block: <ListValue: [StructValue([('code', 'kubectl get -f org-restricted-psp'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fee682e89a0>)])]>

PSP のミューテーション

既存の Pod Security Policy には、検証機能に加えて、デフォルトを構成するためのミューテーション用アドミッションコントロールが含まれている場合があります。現在 PSP ミューテーションを利用していない場合は、ミューテーションの移行も構成も不要です。たとえば、PSP「privileged」の例にはミューテーションが含まれていません。PSP ミューテーションを利用する場合は、以前に PSP ミューテーションによって設定された値すべてを含めるように Pod と PodTemplate の構成を直接更新するとよいでしょう。移行前にすべての PSP ミューテーションを削除することをおすすめします。これは、ミューテーションによって、ポリシーの GitOps とシフトレフトの実装が難しくなるためです。ただし、ビジネス上の理由から必要な場合は、Policy Controller を使用してミューテーションを実装できます。

ミューテーションの移行

既存の PSP が変更を加えているかどうかを確認するには、Pod および PodTemplate のソース構成を PSP クラスタ上で実行されているリソースと比較し、ソース構成にすべての変更を追加します。

ミューテーションの構成

Policy Controller のリソースミューテーション機能を使用して、ご自身の環境に同様のミューテーションを実装することもできます。Policy Controller のデフォルトではミューテーションは無効になっているため、使用する前に有効にする必要があります。Policy Controller のミューテーションは GKE Autopilot クラスタではサポートされていません。

たとえば、PSP「restricted」には「allowPrivilegeEscalation: false」が含まれています。この場合、.securityContext.allowPrivilegeEscalation の値を指定せずに作成された spec.containers と spec.initContainers にデフォルト値 false が構成されます。このミューテーション動作は、以下の Assign オブジェクトを使用して spec.containers にレプリケートできます。この場合、値を指定しないで作成された spec.containers[*].securityContext.allowPrivilegeEscalation が false に設定されます。

code_block: <ListValue: [StructValue([('code', 'apiVersion: mutations.gatekeeper.sh/v1\r\nkind: Assign\r\nmetadata:\r\n name: allow-privilege-escalation-container\r\nspec:\r\n match:\r\n namespaces: ["default"]\r\n applyTo:\r\n - groups: [""]\r\n kinds: ["Pod"]\r\n versions: ["v1"]\r\n location: \'spec.containers[name: *].securityContext.allowPrivilegeEscalation\'\r\n parameters:\r\n assign:\r\n value: false\r\n pathTests:\r\n - subPath: \'spec.containers[name: *].securityContext.allowPrivilegeEscalation\'\r\n condition: MustNotExist'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fee682e8310>)])]>

変更のテスト

既存の PSP を無効にする前に、ミューテーションを含まない「privileged」PSP を適用してワークロードのサンプルをテストする必要があります。問題を発見した場合は、必要に応じて既存の Pod Security Policy とアドレスに簡単にロールバックできます。該当する場合は、PSP バンドルを deny 適用アクションに設定できます。構成を一定期間、十分にテストしたら、既存の PSP を無効にできます。

ダッシュボードでの Pod Security Policy 違反の確認

クラスタでの違反は、Policy Controller ダッシュボードを使用して UI からも確認できます。

Policy Controller ダッシュボード

クラスタでの Pod Security Policy バンドル違反のモニタリング

PSP バンドルでは、デフォルトで適用アクションが dryrun に設定されています。この構成では、リソースをブロックまたは中止することなく Policy Controller によって違反が表示されます。これにより、クラスタの監査、ワークロードオーナーとの違反の共有、重要なセキュリティ問題の共同修正が可能になります。

すべてのポリシー違反は自動的に Cloud Logging に記録され、ログエクスプローラで以下のフィルタを適用して見つけることができます。

code_block: <ListValue: [StructValue([('code', 'resource.type="k8s_container"\r\nresource.labels.namespace_name="gatekeeper-system"\r\nresource.labels.pod_name:"gatekeeper-audit-"\r\njsonPayload.process: "audit"\r\njsonPayload.event_type: "violation_audited"\r\njsonPayload.constraint_name:*\r\njsonPayload.constraint_namespace:*'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fee682e8cd0>)])]>

Cloud Monitoring を使用して、ポリシー違反向けにログベースのアラートを設定することもできます。

Policy Controller には、制約の数、制約テンプレート、検出された監査違反などをはじめとする、ポリシーの使用に関連する指標が含まれています（公開された指標のリストを参照）。インストール時にこれらの指標を Cloud Monitoring と Prometheus、またはそのどちらかにエクスポートできます（ブログ投稿、ドキュメント）。また、指標に基づいてアラートを設定することもできます。

まとめ

Policy Controller により、Google によって作成、管理されるポリシーバンドルとカスタムポリシーの両方をクラスタに適用できます。これにより、Kubernetes API に対する変更がセキュリティ、運用、コンプライアンスの管理に違反することを防止します。また、リソースのミューテーションを実装するとき、または Kubernetes クラスタへのデプロイ前にコンプライアンスを確認するために構成を分析するときに、必要に応じて Policy Controller を使用することもできます。

今すぐ使用を開始する

Policy Controller の使用を開始する際は、Policy Controller をインストールし、Google によって作成、管理されている他のポリシーバンドルを試す方法が最も簡単です。

- Google Cloud、プロダクトマネージャー Poonam Lamba
- Google Cloud、テクニカルソリューションコンサルタント Andrew Peabody

コンテナ化されたマネージドマイクロサービスでモダナイゼーションを加速させる Ulta Beauty

Tue, 28 Mar 2023 01:30:00 +0000

※この投稿は米国時間 2023 年 3 月 17 日に、Google Cloud blog に投稿されたものの抄訳です。

未来のデジタル店舗を開設する

Ulta Beauty は、バランスのとれた視点で明日を見据えながら、来るべきデジタル店舗の礎を築いてきました。この革新的なデジタルタッチポイントは、高度なパーソナライズに向けて再設計された魅力的な e コマースエクスペリエンスを提供します。そのようなエクスペリエンスを適切に提供するために、Ulta Beauty は、最新のコンテナ化されたプラットフォーム、迅速なアプリケーション開発をサポートするアジャイルなインフラストラクチャ、多忙なチームの運用面の負担を軽減するマネージドサービスを必要としています。そのため Google Cloud を使用して、グローバルな規模で効率的にスケーリングする e コマースプラットフォームを提供し、すべての人のために魅力的で楽しく利用しやすいショッピングエクスペリエンスを実現しています。

2019 年に、Ulta Beauty は自社のオンプレミスデータセンターで運用していた従来の e コマースプラットフォームからの移行を開始しました。モノリシックなプラットフォームはアップデートとアップグレードが次第に困難になり、新機能の導入が妨げられていました。Ulta Beauty は、こうしたボトルネックを考慮して、開発チームが新機能の構築、テスト、修正のリリースをより迅速に行えるように、独自の機能を実行する複数のマイクロサービスへのリファクタリングを行うことにしました。マイクロサービスは個別にスケーリングできますが、相互に接続されていて相互に監視可能であり、システムの新たな複雑性が大規模に生じる可能性があります。Ulta Beauty にとって重要だったのは、マイクロサービスを迅速にデプロイし、サービスを相互に統合するときや、基盤となるインフラストラクチャ自体を管理するときに、不要な混乱を回避することでした。

Ulta Beauty が Google Cloud を選んだ理由は、コンテナと Kubernetes に関するその主導的な地位と専門知識、およびその統合マネージドコンテナサービスである Google Kubernetes Engine（GKE）と Anthos にありました。それに加えて、Google Cloud のクラウドベースのマネージドサービス、知識豊かな技術サポート、費用対効果の高い料金設定も魅力でした。

魅力的なパートナーシップ

シニアクラウドアーキテクトの Michael Alderson 氏が Ulta Beauty に入社したとき、Kubernetes と Google Cloud の経験はありませんでしたが、コンテナについては理解していました。モダナイゼーションへの取り組みを開始した Alderson 氏は、インフラストラクチャを構築および管理する新しい方法を模索し、発見するとすぐに開発者の手に渡しました。

Alderson 氏は生産性がさまざまな影響を受ける可能性があることを認識しており、開発者がクラウドの「ランディングゾーン」を必要とするときはいつでも、適切に構成されたランディングゾーンを備えた環境を整える必要がありました。開発者はコンテナの構築に懸命に取り組みましたが、本番環境に近い開発環境やテスト環境がありませんでした。Alderson 氏は次のように語ります。「開発者は、インテグレーションに必要な新しい API でコンテナをテストできませんでした。GKE と Anthos を使用すると、必要なときにいつでも Google Cloud 上に開発環境を作成できるので、生産性が 10 倍になります。」

クラウドアーキテクトになりたてだった Alderson 氏は、Google Cloud のトレーニング passway と認定資格について知識を深めました。実験的な精神に基づいて、同氏は Kubernetes、コンテナ、コンテナ化されたマイクロサービスの大規模なフリートを管理するためのサービスメッシュの役割の研究に取り掛かりました。

優先事項は GKE を機能させることでした。Alderson 氏とチームは、まもなく Kubernetes によって管理されるエフェメラルコンテナ環境の主要なメリットを発見しました。それは、巨額の先行投資をしなくても、アイデアをすばやく試し、学習し、再試行できることでした。

IT チームは Google Cloud と GKE を使用して、記録的な速さで開発者向けのコンテナプラットフォームの作成、管理、最適化を行い、安全性と安定性を確保できるようになりました。「私たちは、おそらく 1,000 を超えるクラスタを構築しては捨て去ることで、Kubernetes を学びました。以前なら、それを達成するのに数か月か数年かかっていたでしょう。」GKE の使用により、開発者は新しい環境の立ち上げと解体を繰り返すことができました。「私たちは、通常なら 5 つのチームによる途方もない努力を必要とするようなベンダーとサービスの統合を達成しました。それを 1 つのまとまったユニットとして成し遂げたのです。このテクノロジーは、かつては考えられないほどに私たちの取り組みを加速させました。」Alderson 氏は次のように言い加えます。「オンデマンドでスピンアップされる GKE 上のエフェメラルコンテナ開発環境では、新機能をマイクロサービスに約 10 分でグローバルにデプロイできます。これは、それまでに必要とされた時間に比べるとほんのわずかです。また、重要なのは、マイクロサービスによってアップデートのリスク要因が大幅に減少することです。」

それでも Alderson 氏は、相互接続された e コマースマイクロサービスの網状組織（それは拡大し、さらに複雑化します）を管理し続ける必要がありました。

Anthos でエンジニアリングリソースを最大限に活用する

ここで Anthos が登場します。Anthos は Google Cloud のマネージドプラットフォームであり、コンテナ化された分散アプリがどこで構築または実行されようとも、一貫性のある包括的な管理、オブザーバビリティ、セキュリティを実現できます。Anthos に含まれているマネージドサービスメッシュを使用すると、サービス配信が大幅に簡素化され、トラフィック管理が容易になります。また、サービス間の通信が保護され、サービス間ネットワーキングの詳細な可視化によりトラブルシューティングが高速化されます。また、サービスメッシュは、アプリ間の通信を簡素化し、どのサービスが相互に通信できるかに関するルールをアサートし、障害が発生した場合にもサービスの高可用性を保証します。

Anthos Service Mesh は、Google によるオープンソースの Istio のフルマネージド実装です。Istio は単独ではパワフルですが、インストール、構成、保守が難しい場合があります。Anthos Service Mesh を使用すると、Google Cloud を通じて Istio コンポーネントを管理できるため、Alderson 氏とチームは Ulta Beauty のアプリの最適化とトラブルシューティングに集中できます。「私たちが組み込んだ指標を使用して、Anthos Service Mesh のネイティブな自動スケーリングと自動修復を行えるため、ゲストエクスペリエンスが向上します。」

「エラー、レポート、そしてまだ明らかになっていない箇所を確認できるので、ゲストエクスペリエンスをより正確に定量化できます。これにより、ソフトウェアの開発とリリースのプロセス（DevOps）を成熟させることができ、ビジネス上の選択とゲストエクスペリエンスの質の向上につながります。今では、このことが Ulta Beauty の競争上の優位性になっています。」さらに、個々のマイクロサービスは Anthos によって動的にインストルメント化されるため、開発者は 1 つのコンポーネントをデバッグしたり、モニタリングとログのデータをトラッキングしたりするために、システム全体を学習する必要がないことを Alderson 氏は言い加えました。

Anthos のもう一つのマネージドサービスである Anthos Config Management では、事前定義されたネットワーキングポリシーとセキュリティポリシーを使用して、標準テンプレートから新しい環境をスピンアップできます。Kubernetes の宣言型の機能を活用することにより、Ulta Beauty は、クラスタのフリート全体に均一な構成を迅速にデプロイし、一貫性のあるセキュリティガードレールを適用して、クラスタおよびリージョン間でロードバランシングを共有できます。Alderson 氏によると、Anthos では必要な環境を定義してから、「...その確立を行い、開発から本番までの環境を自動的に同じ状態に保つことができます。私たちは、新しい e コマースプラットフォームで 70 から 80 の異なるインテグレーションをテストしなければなりません。Anthos がなければ、開発環境とテスト環境でそれらを整理するために、月に 1 週間を費やす必要があるでしょう。Anthos は、すべてを自動的に最新の状態に維持してくれます。」

Ulta Beauty は、Anthos マルチクラスタ Ingress の組み込みのトラフィックルーティングにより、特定のサードパーティサービスでオーケストレーションを支援する必要性を除去できます。同社のセキュリティチームから、組織のセキュリティ体制を強化するために既存のファイアウォールへのアップグレードを要求されたとき、Alderson 氏はそれが不要な理由と、それを行うと実際にパフォーマンスがどのように妨げられるかを説明しました。「必要のない次世代のファイアウォールに多額の投資をしなくても、この問題はメッシュ内で解決できます。また、そうあるべきでしょう。それは、あくまでネットワークの一部であり、パフォーマンスを低下させる別の要因であってはなりません。」Ulta Beauty は、Anthos の組み込みのトラフィックルーティングを使用することで、追加のライセンス料金を数十万ドル節約しました。

Alderson 氏にとって、GKE と Anthos にサーバーをスピンアップする柔軟性があることは、開発者がコードをテスト、解体、再試行して実践的に学習できることを意味します。「間違いを犯しても咎められないことが重要です。私たち全員に必要なのは実践を通して学ぶことであり、Google Cloud はそれを可能にしてくれます。」

Anthos の使いやすさによって Ulta Beauty の e コマースのモダナイゼーションは加速しており、組織のビジネスワークフローはすでに向上しつつあります。どこでも利用できる Anthos クラウドサービスに移行すると、プラットフォームの可用性を Google Cloud にオフロードすることで、リスクが減少し、エラーの重大さが軽減されます。Alderson 氏が 2 か月以上リモート勤務を余儀なくされたときも、チームは問題なく機能し、イノベーションを進めました。

新しいサービスメッシュの実装以降、Ulta Beauty のモダナイゼーションは急速に進行しています。これは、特に開発チームがセキュリティやプラットフォームの運用に専念する必要がなくなり、魅力のあるゲストサービスとアプリの構築に集中できるためです。今では、エラーからの平均復旧時間（MTTR）は時間単位ではなく秒単位で測定されるようになり、少なくとも 2 桁分高速になりました。エラーの追跡は、影響を受けるクラスタまたは Pod まで迅速に行われるようになり、他のコンポーネントに影響を及ぼすことなく（重要な点としては、ゲストエクスペリエンスに影響を及ぼすことなく）エラーを修復できるようになりました。応答の高速化と MTTR の大幅な短縮により、Ulta Beauty のゲストはウェブサイト上の購入プロセス全体を通して優れたエクスペリエンスを享受できます。

今後の展望

Ulta Beauty は、将来を見据えてこの短期間でどこまで到達したかを評価しており、今後も Anthos Service Mesh を重要なコンポーネントとして活用する予定です。次の 1 年をかけて、Alderson 氏とチームは Google Cloud のマルチリージョン機能を活用し、クラスタに障害が発生した場合のアプリケーションの可用性と障害復旧力を向上させる予定です。Anthos と GKE は、インフラストラクチャが利用できないときに、ワークロードの再分散をシームレスに処理します。Ulta Beauty が新しいサービスとエクスペリエンスのイノベーションとデプロイを進める一方で、Google は引き続き同社の環境の管理を行い、開発者がショッピングエクスペリエンスをゲストと同じくらい魅力的なものにできるよう支援します。Google Cloud は、Ulta Beauty とパートナーシップを築き、良いときも悪いときも、どのような状況でも同社の開発者をサポートしていることを誇りに思います。

- Ulta Beauty、シニアクラウドアーキテクトMichael Alderson 氏
- アウトバウンドプロダクトマネージャーDave Bartoletti

新しい PCI DSS ポリシーバンドルで Kubernetes クラスタを強化し、ワークロードのコンプライアンスを大規模にモニタリングする

Thu, 16 Feb 2023 03:15:00 +0000

※この投稿は米国時間 2023 年 2 月 9 日に、Google Cloud blog に投稿されたものの抄訳です。

PCI DSS は、PCI Security Standards Council で採択された一連のネットワークセキュリティおよびビジネス上のベストプラクティスガイドラインによって構成され、お客様の支払いカード情報を保護するための「最小限のセキュリティ基準」が設定されています。Google Cloud は少なくとも年に 1 回、第三者監査を実施し、PCI DSS に照らして個々のプロダクトの認証を受けています。お客様はこうした証明書に基づいて、アプリケーションのコンプライアンスを測定できます。このブログ投稿では、新しいアプリケーションと既存のアプリケーションを評価して PCI DSS のコンプライアンス状況を確認できるようにします。

Policy Controller を使用すると、クラスタに対して完全にプログラム可能なポリシーを適用できます。ポリシーバンドルは、すぐに使える一連の制約で、Google Cloud によって作成、管理されます。ポリシーバンドルにより、Kubernetes 基準、業界基準、Google Cloud 推奨のベストプラクティスに照らしてクラスタリソースを監査できます。多くのポリシーバンドルはすぐに利用可能であり、新規ユーザーでも既存ユーザーでもそのまま、つまり 1 行もコードを記述することなく簡単に使用できます。Policy Controller ダッシュボードを使用して、クラスタのフリートに対するポリシーバンドルのカバレッジとコンプライアンスの状況を確認することもできます。

PCI DSS v3.2.1 ポリシーバンドル

組織のセキュリティ管理者は、PCI DSS ポリシーバンドルの違反を確認することで、PCI DSS の要件に対するアプリケーションの対応状況を確認できます。PCI DSS バンドルの各制約には PCI DSS コントロール番号も設定されており、この番号を PCI の要件にマッピングできます。このマッピングはコンプライアンス報告時に必要に応じて使用できます。違反リストを表示する方法については、この投稿の次のセクションで説明します。

PCI DSS v3.2.1 ポリシーバンドルのポリシーは、次の分野に焦点を当てています。

安全なネットワークとシステム

すべてのアプリに特定の監査ラベルを含めることを必須にすることで、ファイアウォールの要件を保証します。
すべてのアプリに特定のアノテーションを含めることを必須にすることで、ネットワーク制御の要件を保証します。
クラスタで定義されているすべての名前空間に NetworkPolicy が必要です。
RoleBinding リソースに有効な app.kubernetes.io/managed-by= ラベルが必要です。
デフォルトのサービスアカウントを使用したリソースの作成を制限します。
Pod がデフォルトの名前空間を使用できないようにします。

安全なシステムとアプリケーション

すべての PeerAuthentication が厳格な mTLS を上書きできないようにします。
アンチウイルス DaemonSet が必要です。
Anthos Config Management のプレゼンスと有効化を適用します。
BackendConfig リソースに Cloud Armor の構成を適用します。

高度なアクセス制御とモニタリング

basic-auth タイプのシークレットの使用を制限します。
Container-Optimized OS を OS イメージとして確実に使用することで、ノード上での一貫性のある正確な時間を確保します。

PCI DSS v3.2.1 ポリシーバンドルを使用する

PCI DSS v.3.2.1 ポリシーバンドルは、Policy Controller v1.14.0 以降がインストールされている Anthos クラスタにインストールできます。含まれているポリシーは、デフォルトでは「監査」モードで構成されているので、既存または新しいワークロードに影響しません。ポリシーバンドルを適用するには、kubectl（以下で手順を説明します）、kpt、または Config Sync を使用できます。

1. Google Cloud CLI をインストールして初期化します。これにより、この手順で使用する gcloud コマンドと kubectl コマンドが提供されます。Cloud Shell を使用する場合、Google Cloud CLI がプリインストールされています。

2. 参照制約と Policy Controller 制約テンプレートライブラリを有効にして、Anthos クラスタに Policy Controller をインストールします。

3. 次の YAML マニフェストを policycontroller-config.yaml という名前のファイルに保存します。このマニフェストでは、特定の種類のオブジェクトを監視するように Policy Controller を構成します。

注: gatekeeper-system 名前空間にすでに既存の構成がある場合は、変更を維持するため、以前にカスタマイズした設定をすべて含める必要があります。

code_block: <ListValue: [StructValue([('code', 'apiVersion: config.gatekeeper.sh/v1alpha1\r\nkind: Config\r\nmetadata:\r\n name: config\r\n namespace: "gatekeeper-system"\r\nspec:\r\n sync:\r\n syncOnly:\r\n - group: "apps"\r\n version: "v1"\r\n kind: "DaemonSet"\r\n - group: "networking.k8s.io"\r\n version: "v1"\r\n kind: "NetworkPolicy"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fee42e9a8e0>)])]>

4. policycontroller-config.yaml マニフェストを適用します。

code_block: <ListValue: [StructValue([('code', 'kubectl apply -f policycontroller-config.yaml'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fee42e9a820>)])]>

4. kubectl でポリシーの制約をプレビューします。

code_block: <ListValue: [StructValue([('code', 'kubectl kustomize https://github.com/GoogleCloudPlatform/acm-policy-controller-library.git/anthos-bundles/pci-dss-v3.2.1'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fee42e9a220>)])]>

5. kubectl でポリシーの制約を適用します。

code_block: <ListValue: [StructValue([('code', 'kubectl apply -k https://github.com/GoogleCloudPlatform/acm-policy-controller-library.git/anthos-bundles/pci-dss-v3.2.1'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fee42e9a070>)])]>

出力は次のようになります。

code_block: <ListValue: [StructValue([('code', 'asmpeerauthnstrictmtls.constraints.gatekeeper.sh/pci-dss-v3.2.1-asm-peer-authn-strict-mtls created\r\nk8sblockcreationwithdefaultserviceaccount.constraints.gatekeeper.sh/pci-dss-v3.2.1-block-creation-with-default-serviceaccount created\r\nk8sblockobjectsoftype.constraints.gatekeeper.sh/pci-dss-v3.2.1-block-secrets-of-type-basic-auth created\r\nk8senforcecloudarmorbackendconfig.constraints.gatekeeper.sh/pci-dss-v3.2.1-enforce-cloudarmor-backendconfig created\r\n...'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fee42e9a040>)])]>

6. ポリシーの制約がインストールされていることを確認し、クラスタ全体で違反の存在を確認します。

code_block: <ListValue: [StructValue([('code', 'kubectl get constraint -l policycontroller.gke.io/bundleName=pci-dss-v3.2.1'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fee42e9afa0>)])]>

出力は次のようになります。

code_block: <ListValue: [StructValue([('code', 'NAME ENFORCEMENT-ACTION TOTAL-VIOLATIONS\r\nasmpeerauthnstrictmtls.constraints.gatekeeper.sh/pci-dss-v3.2.1-asm-peer-authn-strict-mtls dryrun 0\r\nNAME ENFORCEMENT-ACTION TOTAL-VIOLATIONS\r\nk8sblockcreationwithdefaultserviceaccount.constraints.gatekeeper.sh/pci-dss-v3.2.1-block-creation-with-default-serviceaccount dryrun 0\r\nNAME ENFORCEMENT-ACTION TOTAL-VIOLATIONS\r\nk8sblockobjectsoftype.constraints.gatekeeper.sh/pci-dss-v3.2.1-block-secrets-of-type-basic-auth dryrun 0\r\n…'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fee42e9a550>)])]>

違反を修正するためには、リソースの yaml を更新することをおすすめします。ガイドラインをご覧ください。違反には、その違反の修正手順も含まれています。修正手順は CLI と Policy Controller ダッシュボードの両方から確認できます。

Policy ダッシュボードで PCI DSS ポリシーバンドルの違反を確認する

クラスタでの違反は、Policy Controller ダッシュボードを使用して UI からも確認できます。

クラスタで PCI DSS ポリシーバンドル違反をモニタリングする

PCI DSS ポリシーバンドルは、デフォルトで適用アクションが dryrun に設定されています。この構成では、リソースをブロックまたは中止することなく Policy Controller で違反が表示されます。これにより、クラスタの監査、ワークロードオーナーとの違反の共有、重要なセキュリティ問題を共同で修正することが可能になります。

すべてのポリシー違反は自動的に Cloud Logging に記録され、ログエクスプローラで以下のフィルタを適用して見つけることができます。

code_block: <ListValue: [StructValue([('code', 'resource.type="k8s_container"\r\nresource.labels.namespace_name="gatekeeper-system"\r\nresource.labels.pod_name:"gatekeeper-audit-"\r\njsonPayload.process: "audit"\r\njsonPayload.event_type: "violation_audited"\r\njsonPayload.constraint_name:*\r\njsonPayload.constraint_namespace:*'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fee42e9a1f0>)])]>

また、ポリシー違反が発生するたびに通知を受け取るようにするため、Cloud Monitoring を使用してログベースのアラートを設定することもできます。

Policy Controller には、制約の数、制約テンプレート、検出された監査違反などをはじめとする、ポリシーの使用に関連する指標が含まれています（公開された指標のリストを参照）。インストール時にこれらの指標を Cloud Monitoring と Prometheus にエクスポートできます（ブログ投稿、ドキュメント）。また、指標に基づいてアラートを設定することもできます。

まとめ

Policy Controller により、Google によって作成、管理されるポリシーバンドルとカスタムポリシーの両方をクラスタに適用できます。これにより、Kubernetes API に対する変更がセキュリティ、運用、コンプライアンスの管理に違反することを防止しますまた、Kubernetes クラスタへのデプロイ前にコンプライアンスを確認するために構成を分析するときに、必要に応じて Policy Controller を使用できます。

使ってみる

Anthos Policy Controller の使用を開始する際は、Policy Controller をインストールし、Google によって作成、管理されている他のポリシーバンドルを試してみることが最も簡単です。

- Google Cloud、プロダクトマネージャー Poonam Lamba
- Google Cloud、テクニカルソリューションコンサルタント Andrew Peabody

新しい GitOps オブザーバビリティダッシュボードを使用して、Kubernetes 構成を大規模に管理する

Thu, 02 Feb 2023 03:10:00 +0000

※この投稿は米国時間 2023 年 1 月 26 日に、Google Cloud blog に投稿されたものの抄訳です。

プラットフォームの管理者やオペレーターの間では、構成（デプロイメント、ポリシー定義、Helm チャート、ConfigMap など）を複数の Kubernetes クラスタにわたって一貫して同期する手段として、Config Sync がすでに使用されています。ところが、問題が 1 つ解決されて歓喜している一方で新たな問題が生じています。それは、構成の同期や障害を複数のクラスタにわたってリアルタイムで可視化することです。大規模な運用には、多数の懸念事項が伴います。たとえば、「構成は同期されているか」「リソースの調整はとれているか」「クラスタ内のどの構成の変更がエンドユーザーの行動に影響しているか」などです。本日ご紹介する構成管理ダッシュボードによって、こうした質問に対する答えを簡単に見つけられるようになります。

新しい構成管理ダッシュボードにより、構成を特定し、望ましい状態と実際の状態の違いを把握できるだけでなく、Config Sync を実行しているクラスタを追跡することもできます。この記事では、新しいダッシュボードの主要コンポーネントと、それが運用上の問題の解決にどのように役立つかについて詳しく説明します。

主要コンポーネント

Dashboard: 1 つまたは複数のクラスタにまたがるすべての構成とリソースの全体的なステータスに焦点を当てます。特定のクラスタまたはパッケージ内の最大の懸念事項も確認できます。

Packages: 複数のクラスタにわたって同期されるクラスタ構成とリソースを格納する Git リポジトリ、Helm チャート、OCI レジストリのことです。同期されたリソースと構成は、パッケージごとまたはクラスタごとに表示できます。同期ステータス、調整ステータス、場所、クラスタでビューをフィルタすることもできます。

一般的な操作

新しい構成管理ダッシュボードは、以前は CLI のみが実行手段であった一般的な操作を念頭に置いて設計されています。これにより、次のことを行えるようになりました。

ダッシュボードから 1 つまたは複数のクラスタに Config Sync を簡単にインストールして、[Settings] タブでインストールステータスを追跡できます。

[Packages] タブでクイックフィルタを使用して、パッケージ内の特定の構成の同期ステータスと調整ステータスを 1 つまたは複数のクラスタにわたって確認できます。同期ステータスとは、Git リポジトリ、Helm チャート、OCI レジストリなどのパッケージからの最新の同期のステータスのことです。調整ステータスとは、Config Sync によって Kubernetes API にデプロイされたときの構成のステータスのことです。

[Packages] タブからエラーメッセージを直接表示して、複数のクラスタにわたってリソースの問題をフィルタし、エラーを特定できます。構成エラーや同期エラーなどの一般的なエラーをダッシュボードから簡単に確認できるようになりました。

すべてのパッケージの同期ステータスと調整ステータスのリアルタイムのスナップショットに加えて、複数のクラスタにわたる Config Sync 全体の健全性をダッシュボードから直接一目で確認できます。

まとめ

構成管理ダッシュボードは、管理者やオペレーターとアプリケーションチームが日々行う以下の重要なタスクに役立ちます。

複数のクラスタにわたって構成とリソースの進行状況をしっかり確認し、クラスタの一貫した動作を確保する。
問題を迅速に特定し、それに応じて適切に対処して、エンドユーザーにとっての価値とサービスレベル目標（SLO）を維持する。

お客様のニーズを満たす、使いやすい構成管理ダッシュボードを作成することは Google にとって重要です。今後は、パッケージのデプロイ、ロールアウト管理、通知などの重要な機能を構成管理ダッシュボードに追加する予定です。今後の情報にご注目ください。また、新しい構成管理ダッシュボードに関するフィードバックもお待ちしております。Cloud コンソールの右上にある質問アイコンをクリックし、[フィードバックを送信] を選択して、ご意見、ご提案をお寄せください。

- プロダクトマネージャー Divyansh Chaturvedi

- DevRel エンジニア Mathieu Benoit

任天堂：新しい汎用ゲームサーバーを Google Kubernetes Engine、Cloud Spanner などを駆使して構築

Wed, 01 Feb 2023 01:00:00 +0000

世界中で愛好されている任天堂株式会社（以下、任天堂）の家庭用ゲーム機「Nintendo Switch」。そのオンラインマルチプレイを担う汎用ゲームサーバーの動作基盤に新たに Google Cloud が採用されました。多くのユーザーとの通信を処理しなければならないこの仕組みを、なぜ Google Cloud 上に構築したのか。どのような工夫を施すことで、安定性・可用性と運用負担の軽減を両立させたのか。構築に携わったエンジニアのお二人に話を伺いました。

利用しているサービス：

Google Kubernetes Engine、Agones、Anthos Service Mesh、Cloud Spanner、Cloud Load Balancing、Cloud Storage、Cloud Monitoring、Cloud Trace、Cloud Logging、BigQuery など

Google Cloud なら Kubernetes や Istio をフルマネージドで使える

今やゲームとインターネットは切り離せないもの。それは「Nintendo Switch」も例外ではありません。フレンドの状況を確認したり、オンラインショップでゲームを購入、ダウンロードしたり、ゲーム内外のさまざまな部分でインターネットが活用されています。そうした中、「オンラインマルチプレイ」はゲームにとって、お客様に注目され、重要視される要素の一つです。多くのタイトルが、インターネットを通じて世界中のユーザーと対戦したり、協力したりといった遊び方を提供しています。

任天堂では「ニンテンドーDS」の頃から、オンラインマルチプレイの取り組みを開始。携帯型ゲーム機「ニンテンドー3DS」（2011 年発売）の時代に、ユーザー認証やマッチメイクなど、多くのタイトルで共通して使う機能を提供する汎用ゲームサーバーを構築し、その後も機能強化を繰り返しながら提供し続けてきました。そうした中、オンラインユーザー数の増加や、ネット環境、プレイ環境の変化を受け、今後、さらにオンラインゲームを発展・普及させていくため、2018 年、新技術も積極的に採り入れた「任天堂プラットフォーム向け汎用ゲームサーバー（NPLN）」を開発することになったと、技術開発部の開発担当、河原太介氏は言います。

「開発が大規模化して携わるエンジニアが増えたことと、利用タイトルの増加を踏まえ、NPLN では『マイクロサービス指向』と『マルチテナント構成』の 2 つをコンセプトにシステム全体をコンテナベースで再設計しています。これらを実現するために、必要な Kubernetes や Istio をフルマネージドで利用できる GKE（Google Kubernetes Engine）と Anthos Service Mesh を擁する Google Cloud は我々のニーズに合致した選択肢でした。また、データベースについても、ひとつのインスタンスの中に複数タイトルのデータを入れるには、耐久性や可用性だけでなく、極めて高いスケーラビリティが必要で、そこに Cloud Spanner がマッチしました。」

2021 年のローンチ後、すでに複数のタイトルで導入が進む

NPLN のサービスはマイクロサービスで構成されており、Anthos Service Mesh でサービスメッシュを管理しています。クライアント（Nintendo Switch）からサービスメッシュのアクセスには Cloud Load Balancing を経由して接続します。GKE 上の各サービスは原則としてすべてステートレスに実装されており、ユーザー情報を含むステートフルな情報は Cloud Spanner や Cloud Storage（GCS）に格納。NPLN から出力されたメトリクスやログは Cloud Monitoring や Cloud Trace、Cloud Logging で収集・蓄積し、その一部は BigQuery に転送して必要に応じて分析できるようにしています。

なお、NPLN サーバーは原則としてマルチテナントで運用されていますが、極度に大きなトラフィックが予測される人気タイトルや、特殊な要件のタイトルについてはシングルテナントとして分離できるハイブリッド構成を実現。Anthos Service Mesh がその複雑化したルーティングを担当しています。

「NPLN には、製品環境と開発環境、検証環境など、複数の論理的な環境が存在し、それらに個別の GKE クラスタを割り当てることで独立して更新できるようにしています。また、マッチメイクの条件設定など、タイトルごとの設定値は環境によらず共通になることもあるため、設定値を集中管理できるように、これらの環境とはさらに別のクラスタに管理用のダッシュボードを用意しました。このクラスタが各環境のクラスタと横断して通信することで、ゲーム開発者が行った設定変更を自動的にすべての環境に反映できるように工夫しています。」（河原氏）

また、オンラインマルチプレイを支えるセッション管理サーバーの運用には、Google のオープンソースプロジェクトである Agones を活用。その狙いについて、技術開発部の開発担当、田中翔也氏は次のように説明します。

「NPLN では、ユーザー間でマッチメイクが成立すると、セッションという単位にまとめます。そして各セッションに、内製の軽量なインメモリデータベース機能を持つセッション管理サーバーである Gamesync を割り当てます。これはそれぞれが独立した Pod になっているのですが、そのライフサイクルは他の GKE クラスタの Pod とは大きく異なっています。そこで、NPLN ではそれを Agones を利用して管理しています。」

こうした仕組みの構築に際し、任天堂は Google Cloud のエキスパートからのコンサルティングを受けられる PSO（Professional Services Organization）を導入しました。

「チームとして Google Cloud を利用した大規模プロダクト開発が初めてだったため、設計に関する専門的なアドバイスや、ローンチのサポートを期待して PSO を導入しました。そのおかげで潜在的な不具合が見つかったり、ローンチ前に対策しておくべき問題を一通り解決したりすることができたので、導入した成果はあったと考えています。特に Cloud Spanner を使いこなすにあたり、我々のワークロードに合わせたチューニングや、Cloud Spanner の特性を考慮した負荷試験の実施方法などをアドバイスいただけたのはありがたかったですね。」（田中氏）

2021 年より運用が開始され、すでにソフトメーカータイトルも含めた複数のゲームタイトルで利用され始めているという NPLN。もちろん、今後も機能強化していく予定で、そこに Google Cloud の各種プロダクトを活用していきたいと河原氏は語ります。

「Cloud Logging など、ログ周辺の機能を今後さらに活用していきたいですね。たとえば、NPLN のログをすべて載せてしまうのは現実的ではないため、GCS や BigQuery と連携する機能をうまく活用して、開発体験とコストの折り合いをつけられないか模索しているところです。もちろん、それ以外にも Anthos をさらに使いこなすことで運用の安定性を高めつつ管理コストを削減したり、Cloud Spanner と BigQuery の連携、Google Cloud Managed Service for Prometheus を導入したりなど、やりたいことはたくさんあり、幅広い知識や興味を持ったエンジニアを求めています。この記事やゲームサーバーに興味を持っていただけたらぜひご検討ください！」（河原氏）

任天堂株式会社

〒601-8501 京都市南区上鳥羽鉾立町 11-1

1889 年に創業し、1983 年に発売した「ファミリーコンピュータ」以降、家庭用ゲーム専用機のハードウェアとソフトウェアの開発・製造・販売を手がけるグローバル企業。2017 年に発売された「Nintendo Switch」は、全世界で 1 億台を超える大ヒット商品となった。2021 年にはユニバーサル・スタジオ・ジャパンにテーマパーク「スーパー・ニンテンドー・ワールド」をオープン。ゲーム以外の分野においても、任天堂 IP の活用を積極的に推し進めている。

インタビュイー（写真左から）

技術開発部プラットフォーム技術開発グループサブマネージャー　河原太介氏

技術開発部プラットフォーム技術開発グループ　田中翔也氏

その他の導入事例はこちらをご覧ください

Kubernetes クラスタにポリシーバンドルを適用してポリシー準拠の状況を大規模にモニタリング

Mon, 30 Jan 2023 02:30:00 +0000

※この投稿は米国時間 2023 年 1 月 24 日に、Google Cloud blog に投稿されたものの抄訳です。

ハイブリッドクラウドやマルチクラウド戦略を採用する企業ユーザーが増加する現在、ワークロードは環境全体に分散されるようになり、一元化されたセキュリティとガバナンスの重要性が高まっています。Anthos は、最新のアプリケーションをあらゆる場所で一貫して大規模に実行するための、Google のクラウド中心（Cloud-Centric）のコンテナプラットフォームです。Anthos Config Management（ACM）は、Kubernetes クラスタのポリシーとセキュリティを自動化するサービスで、Config Sync、Config Controller、Policy Controller により構成されています。Config Sync は、クラスタの状態を 1 つ以上の Git リポジトリと調整します。Config Controller は、管理者が Google Cloud Platform（GCP）リソースを宣言型で管理できるようにするホスト型サービスです。このブログ記事では、Policy Controller コンポーネントに追加された機能拡張について取り上げます。

ACM の主要コンポーネントである Policy Controller を使用すると、クラスタに対して完全にプログラム可能なポリシーを適用できます。こうしたポリシーは「ガードレール」として機能し、セキュリティ、運用、またはコンプライアンスの管理に違反する変更を防止します。Policy Controller は、デベロッパーが迅速かつ安全にコードをリリースできるようにすることで、アプリケーションのモダナイゼーションへの取り組みを加速させます。

このたび、クラスタのフリートに適用されるポリシーガードレールを簡単に管理、モニタリングできるパワフルなツールとして、新しい組み込みの Policy Controller ダッシュボードをリリースいたしました。

プラットフォームとセキュリティ管理者は Policy Controller ダッシュボードを使用して、次のことを実現できます。

適用ステータス（dryrun または enforced）など、クラスタのフリートに適用されたすべてのポリシーの状態を一目で確認
各違反に対する独自の推奨事項を参照することで、ポリシー違反を容易にトラブルシューティングして解決
クラスタリソースのコンプライアンスステータスを可視化

Anthos の Policy Controller ダッシュボード

このダッシュボードでは、特定のポリシーの影響を受けるリソースを表示して、問題の解決方法について独自の提案を行うこともできます。

脆弱性の影響を受けるリソースを特定

ポリシーバンドルの概要

ポリシーバンドルは、すぐに使える一連の制約で、Google によって作成、管理されます。このバンドルにより、Kubernetes 基準、業界基準、または Google 推奨のベストプラクティスに照らしてクラスタリソースを監査することができます。

ポリシーバンドルはすぐに利用可能で、新規ユーザーでも既存ユーザーでもそのまま、つまり 1 行もコードを記述することなく簡単に使用できます。ユーザーは、Policy Controller ダッシュボードから、フリートに対するポリシーバンドルのカバレッジの状況を確認できます。たとえば、フリート内に 4 つのクラスタがあり、この 4 つのクラスタすべてに PCI DSS 3.2.1 バンドルを適用した場合、ダッシュボードにはフリートのカバレッジが 100% であることが表示されます。また、カバレッジに加え、ダッシュボードにはクラスタのフリート全体に対する、各バンドルの包括的なコンプライアンスステータスも表示されます。

Anthos では、現在以下のポリシーバンドルを利用できます。

PCI DSS 3.2.1: PCI-DSS 3.2.1 業界基準に照らしてクラスタリソースの監査を行う
CIS Kubernetes Benchmark 1.5.1: CIS Kubernetes Benchmark（Kubernetes を構成し、堅牢なセキュリティ体制をサポートするための一連の推奨事項）に照らしてクラスタリソースの監査を行う
PSS Baseline: PSS - Baseline に照らしてクラスタリソースの監査を行う
PSS Restricted: PSS - Restricted に照らしてクラスタリソースの監査を行う
PSP: Pod のセキュリティポリシーに照らしてクラスタリソースの監査を行う
Policy Essentials: コンテナ化されたワークロード向けに、Google 推奨のベストプラクティスに照らしてクラスタリソースの監査を行う
Anthos Service Mesh セキュリティ : 推奨される Anthos Service Mesh のベストプラクティスに対してクラスタの監査を行う

使ってみる

Anthos Policy Controller の使用を開始する際は、Policy Controller をインストールし、CIS ベンチマークなどの基準に照らしてクラスタのフリートを監査するためにポリシーバンドルを適用してみることが最も簡単です。

また、Policy Essentials バンドルに照らしてクラスタを監査するために、Policy Controller を試すこともできます。

- Google Cloud、プロダクトマネージャー Poonam Lamba

Anthos Service Mesh によるマルチクラスタ Ingress の一元化

Mon, 09 Jan 2023 11:14:00 +0000

※この投稿は米国時間 2022 年 12 月 16 日に、Google Cloud blog に投稿されたものの抄訳です。

ツールをきっかけとしてオープンソースプロダクトが普及するという Kubernetes で見られたような現象は、これまでには見られなかったものです。Kubernetes が安全かつ確実にサービスを実行する事実上のコンテナオーケストレーターとなっているのは、こうした構成要素があるためです。Kubernetes は単独で実行されるわけではなく、多くの場合、Kubernetes がネイティブには解決できないビジネス上の現実課題を解決できるよう、その他のツールとともにデプロイされます。Google は、そうしたプロダクトのマネージドコレクションを Anthos 傘下で提供しています。

本記事では、Anthos を活用し、マルチクラスタ Ingress（MCI）と Anthos Service Mesh（ASM）でインターネットトラフィックの管理を一元化する方法について説明します。

問題提起

大規模な組織にとって、責務の分離は大きな懸念事項です。クラウド基盤の設計も、この懸念によって決まることになります。プロジェクトは、Google Cloud Platform が提供するリソースの大半に対して最小権限戦略を策定する際の境界線となるものです。よって、チームが違えばワークロードを実行するプロジェクトも分かれていると言っていいでしょう。

こうした責務の分離は、ネットワーキングの管理にも当てはまります。共有 VPC は、チームがネットワーキングを一元的に管理するためのツールの一つです。これを使うと、複数のプロジェクトで同じ VPC を共有できます。VPC が同じであることは、Anthos の提供する一部の機能の要件にもなっています。

Kubernetes で実行されるアプリケーションは、時としてインターネットに公開する必要があります。アプリケーションの公開には、ロードバランサを使用できます。ロードバランサのライフサイクルと構成の管理は、アノテーションとカスタムリソース定義（CRD）によって行われます。MCI は、Kubernetes 上で実行されているサービスをインターネットに公開するうえで Google Cloud グローバルロードバランサ（GLBC）のライフサイクルを管理するマネージドコントローラです。残念ながら、GLBC はクロスプロジェクトのバックエンドには対応していません。最小権限戦略を導入するうえでの基盤はプロジェクトです。よって、1 つの解決策として、プロジェクトごとに GLBC をデプロイするという方法が考えられます。ただ、この方法の場合、ネットワークチームやセキュリティチームに相当の管理上のオーバーヘッドがかかります。もう 1 つの解決策は、MCI を使って 1 つの GLBC をデプロイし、ASM を使いクロスプロジェクトでトラフィックをルーティングするというものです。この方法ならば、セキュリティチームも、混乱や偶発的な構成エラーの発生を最小限に抑えつつ、責任をシームレスに分離して、必要な責務の分離を実現できます。

ここまでで、解決しようとしている問題の内容と使用するツールについて説明してきました。続いて、解決方法について詳しく見ていきましょう。

アーキテクチャの図

このアーキテクチャは、マルチプロジェクト設定で MCI をサポートする場合の推奨ソリューションです。フリートプロジェクトとサービスプロジェクトが同じ VPC を共有しています。共有 VPC ホストプロジェクトはこの図には描かれていませんが、別個のプロジェクトとなっています。フリートプロジェクトとは、Fleet API が有効になっているプロジェクトのことです。同じフリートに属するすべてのクラスタは、属するメッシュも同じになります。MCI の構成をホストしているのはフリート GKE クラスタの片方ですが、構成を両方のフリート GKE クラスタにデプロイすることで高可用性を実現しています。両方のクラスタに同じ構成をデプロイすることで、構成クラスタの入れ替えを簡単に行えるようにしています。

一方、サービスプロジェクトはワークロードをホストしています。開発チームは、管理するサービスをデプロイする際、Namespace にアクセスすることになります。

このソリューションの導入方法

このソリューションを導入するうえで重要なのは、トラフィックの流れについて詳細に把握することです。以下の手順では、すべてが正常に動作していることを確認するためのプロセスを説明します。作業を始める前に、以下を実施します。

MCI がセットアップされていることを確認します。
マネージド ASM が有効であることを確認します。

code_block: <ListValue: [StructValue([('code', '$ kubectl -n istio-system get controlplanerevision\r\nNAME RECONCILED STALLED AGE\r\nasm-managed-stable True False 34d'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fee683703d0>)])]>

Ingress ゲートウェイなどのリソース用の Namespace を作成します。

code_block: <ListValue: [StructValue([('code', "$ export INGRESS_NS=ingress\r\n$ export ASM_REVISION=$(kubectl -n istio-system get controlplanerevision | awk '/asm/ {print $1}')\r\n$ cat > ns_ingress.yaml << EOF\r\napiVersion: v1\r\nkind: Namespace\r\nmetadata:\r\n labels:\r\n istio.io/rev: ${ASM_REVISION}\r\n name: ${INGRESS_NS}\r\nEOF"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fee683702e0>)])]>

Ingress の Namespace で、Ingress Deployment と Ingress ゲートウェイを作成します。なお、これをデプロイするのは、フリート GKE クラスタだけです。
マルチクラスタサービスリソースをデプロイし、デプロイした Ingress コントローラにセレクタを使用してトラフィックを送信します。クラスタの spec のリンクは、ASM の Ingress リソースがデプロイされているフリート GKE クラスタのみとします。マルチクラスタサービスリソースでネットワークエンドポイントグループ（NEG）を作成します。

code_block: <ListValue: [StructValue([('code', '$ export INGRESS_NS=ingress\r\n$ cat > mcs.yaml << EOF\r\napiVersion: networking.gke.io/v1\r\nkind: MultiClusterService\r\nmetadata:\r\n annotations:\r\n networking.gke.io/app-protocols: \'{"http":"HTTP"}\'\r\n name: mcs-service\r\n namespace: ${INGRESS_NS}\r\nspec:\r\n clusters:\r\n - link: us-east4/fleetclustereast\r\n - link: us-central1/fleetclustercentral\r\n template:\r\n spec:\r\n ports:\r\n - name: https\r\n port: 80\r\n protocol: TCP\r\n targetPort: 80\r\n selector:\r\n asm: ingressgateway # Ingress コントローラで同じセレクタを定義\r\nEOF'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fee68370a00>)])]>

GLBC を作成するには、マルチクラスタ Ingress リソースをデプロイする必要があります。

code_block: <ListValue: [StructValue([('code', 'cat > mci.yaml << EOF\r\napiVersion: networking.gke.io/v1\r\nkind: MultiClusterIngress\r\nmetadata:\r\n name: mci\r\nspec:\r\n template:\r\n spec:\r\n backend:\r\n serviceName: mcs-service # マルチクラスタサービスの名前\r\n servicePort: 80\r\n rules:\r\n - host: "store.store.svc.cluster.local"\r\n http:\r\n paths:\r\n - backend:\r\n serviceName: mcs-service\r\n servicePort: 80\r\nEOF'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fee683704f0>)])]>

サービスの Namespace を作成します。次の構成を、すべてのクラスタに適用する必要があります。その際、Anthos Config Management（ACM）を利用できます。

code_block: <ListValue: [StructValue([('code', "$ export STORE_NS=store\r\n$ export ASM_REVISION=$(kubectl -n istio-system get controlplanerevision | awk '/asm/ {print $1}')\r\n$ cat > ns_store.yaml << EOF\r\napiVersion: v1\r\nkind: Namespace\r\nmetadata:\r\n labels:\r\n istio.io/rev: ${ASM_REVISION}\r\n name: ${STORE_NS}\r\nEOF"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fee68370f70>)])]>

MCI 用にデプロイされたゲートウェイをリッスンする仮想サービスを作成します。ゲートウェイの属性は、Namespace と使用するゲートウェイの名前を組み合わせたものです。この仮想サービスは、フリート GKE クラスタに作成する必要があります。

code_block: <ListValue: [StructValue([('code', '$ export STORE_NS=store\r\ncat > ingress_virtual_service.yaml << EOF\r\napiVersion: networking.istio.io/v1alpha3\r\nkind: VirtualService\r\nmetadata:\r\n name: frontend\r\n namespace: ${STORE_NS}\r\nspec:\r\n hosts:\r\n - "store.store.svc.cluster.local"\r\n gateways:\r\n - asmingress/ingressgateway\r\n http:\r\n - route:\r\n - destination:\r\n host: store\r\n port:\r\n number: 80\r\nEOF'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fee683705e0>)])]>

2 つめの仮想サービスは、ワークロードが実行されているクラスタに作成する必要があります。最初の仮想サービスとの違いは、こちらの場合に使用するゲートウェイは、Ingress ゲートウェイが別のプロジェクトにデプロイされているため、メッシュである必要があるという点です。

code_block: <ListValue: [StructValue([('code', '$ export STORE_NS=store\r\ncat > virtual_service.yaml << EOF\r\napiVersion: networking.istio.io/v1alpha3\r\nkind: VirtualService\r\nmetadata:\r\n name: frontend\r\n namespace: ${STORE_NS}\r\nspec:\r\n hosts:\r\n - store.store.svc.cluster.local\r\n gateways:\r\n - mesh\r\n http:\r\n - route:\r\n - destination:\r\n host: store\r\n port:\r\n number: 80\r\nEOF'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fee68370190>)])]>

サービス GKE クラスタにワークロードをデプロイします。

code_block: <ListValue: [StructValue([('code', '$ export STORE_NS=store\r\n$ cat > store.yaml << EOF\r\napiVersion: apps/v1\r\nkind: Deployment\r\nmetadata:\r\n name: store\r\n namespace: ${STORE_NS}\r\nspec:\r\n replicas: 2\r\n selector:\r\n matchLabels:\r\n app: store\r\n version: v1\r\n template:\r\n metadata:\r\n labels:\r\n app: store\r\n version: v1\r\n spec:\r\n containers:\r\n - name: whereami\r\n image: us-docker.pkg.dev/google-samples/containers/gke/whereami:v1.2.11\r\n ports:\r\n - containerPort: 8080\r\nEOF'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fee6e874760>)])]>

フリート GKE クラスタとサービスクラスタの両方に、Deployment 用のサービスをデプロイします。これは、サービスディスカバリのために必要となるものです。

code_block: <ListValue: [StructValue([('code', '$ export STORE_NS=store\r\n$ cat > store_svc.yaml << EOF\r\napiVersion: v1\r\nkind: Service\r\nmetadata:\r\n name: store\r\n namespace: ${STORE_NS}\r\nspec:\r\n selector:\r\n app: store\r\n ports:\r\n - port: 80\r\n targetPort: 8080\r\nEOF'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fee6e8743d0>)])]>

最後に、サービスが応答するかどうかをテストします。これには curl を利用できます。たとえば次のとおりです。

code_block: <ListValue: [StructValue([('code', '$ curl --header "Host: store.store.svc.cluster.local" http://${GLBC_IP} -v'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fee6e874dc0>)])]>

まとめ

本ブログ投稿では、MCI は異なるプロジェクトのバックエンドには対応していないものの、ASM を使えばこの制約を克服できるということを説明しました。これら 2 つのプロダクトを組み合わせれば、トラフィック管理を一元化したり、異なるプロジェクトで実行されているワークロードに同じ GLBC を使いまわしたりといったことを簡単に実行できます。GKE Ingress のその他の例については、GKE ネットワークレシピのリポジトリをご覧ください。

- プロフェッショナルサービス Ahmed Belgana
- Google、シニアクラウドアーキテクト Hamza El-Ghoujdami

Multicloud Mindset: マルチクラウドの世界におけるオープンソースとセキュリティについて考える

Thu, 24 Nov 2022 10:10:00 +0000

※この投稿は米国時間 2022 年 11 月 17 日に、Google Cloud blog に投稿されたものの抄訳です。

今こそマルチクラウドについてお話しするときです。そのために、Twitter スペース上で Google Cloud Multicloud Mindset シリーズを作成しました。このシリーズでは、2 週間に一度、マルチクラウドに関する最新のトピックについて、トップクラスのエキスパートによる会話をライブでお届けします。15 分間の Q＆A に参加すると、最も知りたいことについてご質問いただけます。また、ライブでの会話が終了してから 30 日間はいつでもオフラインでエピソードを視聴できます。

これまでのエピソードを聴き逃した場合は、このシリーズの紹介ブログで内容をご確認になることをおすすめします。今回は、マルチクラウド環境におけるオープンソースの影響と新たなセキュリティ課題について説明した、最近のエピソードについて詳しくご紹介します。

エピソード 5: オープンソースとマルチクラウドの交わるところ

オープンソーステクノロジーは、コンピューティングの初期時代からその不可欠な一部であり、シリコンバレーのようなテクノロジー拠点が誕生する以前から存在しています。Mozilla Firefox や Linux オペレーティングシステムなど、世界で最も有名なソフトウェアのいくつかはオープンソースプロジェクトから生み出されました。

エピソード 5 では、Google Cloud の Cloud デベロッパーアドボケイト Mike Coleman とともに、オープンソーステクノロジーの歴史、マルチクラウドの世界で果たす役割、オープンソーステクノロジーを使用した作業に対するデベロッパーの視点について詳しく取り上げました。

マルチクラウドのコンセプトは、異なるクラウドをまたいでワークロードを実行できることと、ワークロードの特定の部分に最適なプロバイダを選択できることに基づいています。企業は、オープンソースのテクノロジーと言語を採用することで、特定のクラウドプロバイダに縛られることを心配せずに、プロバイダに関係なく必要なツールを使用することができます。

「クラウドからクラウドへの移動でも、デベロッパーのパソコンからデータセンターやクラウドなどへの移動でも、オープンソースソフトウェアでは環境間の移動が可能です。マルチクラウドはその延長にすぎません。場所がどこであっても同じソフトウェアを実行する必要があるという考え方です。」- Google Cloud、Cloud デベロッパーアドボケイト Mike Coleman

ソフトウェア開発およびデジタルトランスフォーメーションのトレンドに対するマルチクラウドとオープンソースの影響を取り上げた、デベロッパーによるセッションにご興味がある方は、このエピソードをご確認ください。

Twitter スペース上で、エピソード全体にアクセスできます。

エピソード 6: マルチクラウドにおけるセキュリティ上の新たな課題

このシリーズのエピソード 6 では、Google Cloud の CISO オフィスのセキュリティアドバイザー Anton Chuvakin 博士を交えて、セキュリティのリーダーやアーキテクトが、マルチクラウド環境への対応がますます難しくなっている従来のセキュリティモデルからどのように脱却しているかについて取り上げました。

マルチクラウドアプローチを採用する組織が増えるのに伴い、このような複雑な環境で、SecOps チームへの負担が増す中、セキュリティをどのように維持するかが最重要課題となっています。Chuvakin 博士が述べたように、従来型のチームが直面しているクラウドの課題は、テレメトリーやログの種類から、ボリューム、検出のユースケースの不明確さまで、多岐にわたります。しかも、複数のクラウドを含むように拡張された環境では、このような問題が深刻化します。こうした環境では、特定のプロバイダでの操作方法が、別のプロバイダとまったく異なることがあるためです。

「最終的にマルチクラウドを採用することになったら、パブリッククラウドについて理解し、またどうすれば単一のプロバイダの場合よりもそれがうまく機能するかについて知る必要があります。3 台の自動車を修理する場合に、まず自動車の修理方法を学ぶ必要があるのと同じです。マルチクラウドを利用するには、クラウドについてより多くの知識が必要になります。より少ない知識でもよいということはありません。1 つのプロバイダについて学んだらそれで終わりではなく、パブリッククラウドコンピューティングの分野にさらに精通する必要があります。」- Google Cloud、CISO オフィスセキュリティアドバイザー Anton Chuvakin 博士

このエピソードで、博士はマルチクラウドのセキュリティに対処するための 3 つのヒントを示しました。

マルチクラウドを採用する場合は、クラウドについてより多く学ぶ。マルチクラウドの場合、1 つのプロバイダについて学んだら終わりではなく、クラウドについてより多くの知識が必要になります。マルチクラウド環境を保護するには、クラウド間の違いを理解する必要があります。
クラウド ID 管理について学び、また従来の ID 管理サービス機能との違いについても学ぶことを重視する。まずは、特定のクラウドで相違点と類似点を特定してから、利用している他のクラウドでも同じことを行います。
検出が複数のクラウド全体で機能するかどうかを把握するために、検出と対応のアクティビティを計画する際に、クラウド環境で脅威の領域が変わる部分を探る。

組織でマルチクラウドを採用する場合は、こちらのエピソードの視聴をおすすめします。クラウドのセキュリティ、セキュリティチームが直面する主な考慮事項と課題、マルチクラウド環境でのセキュリティについて考えるうえで役立つベストプラクティスについてご確認いただけます。

このブログシリーズでは毎月、最新のトピックとエピソードをご紹介します。次回もご期待ください。

- Google Cloud、プロダクトマーケティングマネージャー Shubhika Taneja

お知らせ: Twitter スペースで Multicloud Mindset シリーズをご紹介

Tue, 04 Oct 2022 01:00:00 +0000

※この投稿は米国時間 2022 年 9 月 24 日に、Google Cloud blog に投稿されたものの抄訳です。

今こそマルチクラウドについてお話しするときです。マルチクラウドは、従来の IT インフラストラクチャをクラウドに「リフト＆シフト」して費用の削減と利便性を図るだけでなく、さまざまなクラウドプロバイダのベストオブブリードサービスを利用して、ビジネス目標を達成する新しい方法を考案し、デジタルトランスフォーメーションを促進します。実際、業界の調査では、89% の企業が最低でも 2 つ以上のパブリッククラウドプロバイダを使用していることがわかっています。

新しい Multicloud Mindset シリーズでは、2 週間に一度、マルチクラウドに関するトピックについて、トップクラスのエキスパートによる魅力的なライブ会話を Twitter スペースでお届けします。差し迫った問題への回答を得るために 15 分の Q＆A へジャンプすることもできます。また、チャット後最大 30 日間は、オフラインで後からエピソードを聞くこともできます。

エピソード 1: 役員室内のマルチクラウド

まず、Cloud Wars の創業者である Bob Evans 氏との対話でシリーズをはじめたいと思います。先進的な企業では、さらなる柔軟性を求めるだけでなく、マルチクラウドを、特定のクラウドプロバイダにより提供されるイノベーションを活用するための極めて重要な方法として考えています。組織で起こっているマルチクラウドについての決定が、なぜほとんどの場合競争上のメリットを確保するために役員室内で行われるのかについて深く掘り下げました。

「マルチクラウド戦略の欠落は、ビジネスに競争上の不利益をもたらします。」 - Cloud Wars、創業者 Bob Evans 氏

経営者がどんなシナリオを計画しているのか、議論されている検討事項、主なトレードオフと課題について、気になったことがある方はぜひ聴いてください。

このエピソードは 30 日以上経過したため、Twitter でのアーカイブは終了しました。すぐにアーカイブ版にアクセスできるように対応し、次回のブログでご紹介する予定です。

エピソード 2: マルチクラウドに関する 5 つのすべきこととすべきでないこと

デジタルトランスフォーメーションのプロセスにおいて、まったく同じ方法でクラウドを使用している人はいないというのが真実です。このシリーズのエピソード 2 では、Google Cloud のアウトバウンドプロダクトマネジメントディレクターである Richard Seroter とともに、マルチクラウドの採用が組織にとって正しい選択である理由と、正しいアプローチを見つけるためのベストプラクティスに関する知見についてご紹介します。

Richard によると、マルチクラウドには、5 つのすべきこととすべきでないことがあります。

すべきこと: 正しい理由でマルチクラウドを選択する - アナリストの言いなりになるのではなく、ビジネスの価値に基づいて「なぜ」マルチクラウドなのかを定義してください。
すべきでないこと: ワークロードやデータポータビリティの過剰なエンジニアリング - 「一度書けば、どこでも実行可能」は、価値以上にトラブルになる可能性があります。その代わりに、ネイティブサービスの明確な価値を考慮し、クラウドにワークフローを持ち込むのではなく、ワークフローをサポートするために使用してください。
すべきこと: さまざまなステークホルダーの関心やニーズを理解する - コンテキストが重要です。気をつけてほしいのは、マルチクラウドを必要とする理由はグループによって異なるということです。このことは全体のアプローチに影響します。
すべきでないこと: 一人で行動する - 業界のコミュニティを上手に活用し、何がうまくいって何がうまくいかないのかについて知識を共有してください。
すべきこと: まずマルチリージョンのデプロイでテストする - マルチリージョンのデプロイから始めることで、マルチクラウドアーキテクチャに挑戦する前に、問題点を解決できます。

マルチクラウドのどの段階にあるかにかかわらず、マルチクラウドとは何か、重要な検討事項、そして最も重要な点として、なぜマルチクラウドを活用すべきなのか（そして活用すべきでないのか）について学べる素晴らしいエピソードです。

こちらから Twitter スペース上のすべての会話にアクセスできます。

エピソード 3: Yugabyte のマルチクラウドへの移行

過去 10 年間、これまでテクノロジー企業ではなかった組織は、競争力を維持するために、マイクロサービス、Kubernetes、マルチクラウドやハイブリッドクラウドを導入し、IT インフラストラクチャを変革する必要がありました。エピソード 3 では、クラウドネイティブアプリのためのオープンソース分散型 SQL データベース、Yugabyte の戦略およびマーケティング担当バイスプレジデントである Suda Srinivasan 氏と、オープンソースとマルチクラウドについて対談します。

「過去 5 年間、多くの企業がアプリのモダナイゼーションに注目していました。現在、それらの企業は、デジタルトランスフォーメーションのデータベースモダナイゼーションのフェーズに移行しており、そのデータベースモダナイゼーションはある種、本当の旅のようです。今後 5 年間は、その多くが、予測可能な未来のためのハイブリッドやマルチクラウドを導入するステージへと移っていくでしょう。」 - Yugabyte、戦略およびマーケティング担当バイスプレジデント Suda Srinivasan 氏

Yugabyte の独自の成功がどのようにオープンソースの力とリンクしているのか、そしてマルチクラウドのためのサービスを構築するとき、データベースについてどのように考えるべきかを議論します。Suda 氏によると、鍵となるのは、異なる環境の不均一性や複雑性を取り除くためにテクノロジーを使用することです。データベースが異なる環境にまたがって動くかどうか、トラブルなくスムーズに動くかどうかという細かい点が、成功へとつながるのです。

Suda 氏によると、鍵となるのは、異なる環境の不均一性や複雑性を取り除くためにテクノロジーを使用することです。データベースが異なる環境にまたがって動くかどうか、トラブルなくスムーズに動くかどうかという細かい点が、成功へとつながるのです。マルチクラウドのためのデータベースをデプロイする際は、さまざまなクラウド環境でテストされ、その環境での動作が保証されたソリューションを選ぶことが重要です。また、Database as a Service（DBaaS）ソリューションを選んだ場合は、さまざまなクラウドでデータベースクラスタをスピンアップして、基盤となるインフラストラクチャやクラウドスタックの複雑性を取り除き、アプリケーションの構築に集中できるようにすべきです。

こちらから Twitter スペース上のすべての会話にアクセスできます。

エピソード 4: クラウドがマルチクラウドへ進化するにつれ、仕事も進化する

すでに Cloud で仕事をしていてキャリアアップの道筋を探している、もしくは Cloud でのキャリアをスタートさせようとしている方は、Google Cloud のプロダクトマーケティングシニアディレクターである Jeana Jorgensen によるこのエピソードは必見です。

Jeana はテクノロジー企業業界に入るまでの驚くべきストーリーでリスナーを魅了しました。Jeana はまた、忍耐力や学び続けることへの好奇心などの特定のスキルが、どのようなバックグラウンドの人が来るかに関係なく、リーダーとしてチームを作る際に求めることの核心であることを共有しました。

次に、クラウドがマルチクラウドへ進化するにつれ、仕事がどのように進化するかについて語りました。Jeana は、オープンソースやコードとしてのインフラストラクチャが、クラウドの専門家がクラウドのジェネラリストとなり、クラウドでのキャリアアップのためのスキルを習得するのに役立つということを説明しました。マルチクラウドを恐れる理由はあるかと尋ねられたとき、Jeana は次のように答えました。

「マルチクラウドは恐れるものではなく、利用すべきものです。」- Google Cloud、プロダクトマーケティングシニアディレクター Jeana Jorgensen

こちらから Twitter スペース上で Jeana との会話にアクセスできます。

このブログシリーズでは、さまざまなマルチクラウドについてのトピックが毎月更新されますので、次回もどうぞお楽しみに。次回の Multicloud Mindset は 2022 年 9 月 30 日 9 時（太平洋標準時）からですので、ぜひお聞きください（詳細は Twitter 上ですぐに共有されます）。

- Google Cloud プロダクトマーケティングマネージャー Shubhika Taneja

オンプレミスのエッジ VM 管理を目的とした Anthos の拡張: 一般提供開始

Mon, 26 Sep 2022 01:20:00 +0000

※この投稿は米国時間 2022 年 9 月 20 日に、Google Cloud blog に投稿されたものの抄訳です。

このたび、Anthos での仮想マシン（VM）サポートの一般提供を開始したことをお知らせいたします。VM サポートは、ベアメタル版 Anthos（現在の名称はGoogle Distributed Cloud Virtual）でご利用いただけます。データセンターまたはエッジで、Google Cloud に接続された単一の統合プラットフォーム上のコンテナと一緒に VM を実行していただけるようになりました。

Anthos での VM サポートによって、開発者と運用チームはクラウドネイティブな共有インフラストラクチャ上で VM をコンテナとともに実行できます。Anthos での VM サポートにより、Kubernetes スタイルの宣言型構成とポリシー適用、セルフサービスでのデプロイ、オブザーバビリティ、モニタリングを使用して、一貫したコンテナと VM のオペレーションを実現できます。これらはすべて、使い慣れた Google Cloud コンソール、API、コマンドラインインターフェースから操作できます。Anthos VM のランタイムは、あらゆる Anthos on bare metal クラスタ（v1.12 以降）で追加料金なしで有効にできます。

プレビュー期間中、小売業のエッジ環境に向けた Anthos での VM サポートに大きな関心が寄せられました。小売業のエッジ環境では、インフラストラクチャのフットプリントが小規模で、少数のホストで新しいコンテナアプリと従来の VM アプリを実行する必要があります。実際に、世界的なクイックサービスレストラン（QSR）では、既存の POS ソリューションにおける単一の VM を使用し、注文のシミュレーションを 1 時間あたり 1,700 件を超えるスループットで 10 時間行い、合計で 17,000 以上を処理しました。この VM は、店舗にあるものと同じハードウェア上で実行しています。

VM 管理のために Anthos を拡張する理由

多くのお客様は、コンテナや Kubernetes を使用して既存の（従来の）アプリケーションをモダナイズしています。しかし、現在のところ、エンタープライズワークロードはほとんどコンテナ化されておらず、何百万ものビジネスクリティカルなワークロードがいまだに VM で実行されています。多くの VM は Google Cloud の VM への移行や、GKE または Anthos 上のコンテナへの移行によってモダナイズできますが、すぐにできないものも含めて、モダナイズできない VM が数多く存在します。

ベンダー提供のアプリに依存しており、コンテナで実行するためのアップデートがまだ行われていないケース、他のローカルアプリまたはインフラストラクチャへの接続時のレイテンシを低く抑える必要があり VM をデータセンターやエッジロケーションに保持する必要があるケース、現時点でカスタムビルドのアプリをコンテナ化するための予算がないケースなどが考えられます。こうした VM をコンテナやクラウドアプリのモダナイゼーション戦略に組み込むには、どうすればよいでしょうか。

Anthos で、VM とコンテナを対象とした一貫した可視性、構成、セキュリティが実現

VM とコンテナを同時に実行、管理する

Anthos での VM サポートの中心にあるのは、オープンソースの KubeVirt テクノロジーを拡張および強化する Anthos VM ランタイムです。インストールとアップデートを簡素化するために、Kubevirt と Anthos on bare metal を統合しています。コマンドライン、API、Google Cloud コンソールを使用して VM を管理するためのツールも提供しています。また、すぐに使用できるダッシュボードやアラートなど、VM のオブザーバビリティログと指標を Google Cloud のオペレーションスイートに統合しました。

Kubernetes Pod との互換性も備えた VM モビリティを実現するために、VM 用の複数ネットワークインターフェースや IP / MAC セッション維持のサポートなど、ネットワークの大幅な機能強化も行っています（マルチ NIC）。また、VLAN 統合を追加するとともに、お客様が L4 Kubernetes ネットワークポリシーを適用して、オンプレミスでの VPC のようなマイクロセグメンテーションを利用できるようにもしました。

VM の管理者としての経験があれば、これまでと同様の操作で、VM の高可用性と簡素化された Kubernetes のストレージ管理を活用して、新たな管理体験を得ることができます。VM のライフサイクル管理は Google Cloud コンソールに組み込まれており、既存の Anthos と Google Cloud の認証および認可フレームワークと統合された、よりシンプルなユーザーエクスペリエンスが用意されています。

Anthos で稼働している VM を Google Cloud コンソールで表示および管理

新しい VM 評価ツールと移行ツールを使ってすぐに開始する

Anthos が VM ワークロードに適したものかどうどうかを判別するには、どうすればよいでしょうか。Google Cloud では、VM のモダナイゼーションにおけるあらゆる段階で役立つ評価ツールと移行ツールを用意しています。アップデートされた適合性評価ツールでは、既存の VMware VM に関するデータを収集して詳細なレポートが作成できます。このレポートの所有権はお客様にあり、費用もかかりません。Google Cloud コンソールにアップロードして、詳細に可視化されたビューと履歴ビューを利用できます。

このレポートによってすべての VM の適合性スコアがわかります。適合性スコアにより、VM をコンテナ化して Anthos または GKE にコンテナとして移行する場合、または VM として Anthos に移行する場合に必要となる作業量を見積もることができます。移行に最適な VM を特定したら、追加の費用負担なしでアップデートされた Migrate to Containers ツールを使用し、コマンドラインまたはコンソールから VM を Anthos に移行できます。

VM として Anthos にシフト（移行）できる VM を示す適合性評価レポートのサンプル

ビジネスクリティカルな VM ワークロードや仮想化管理に投資することで、クラウドやコンテナアプリのモダナイゼーションの目標達成が遠ざかるような事態は避けるべきです。これからは、オンプレミスで管理するコンテナのプラットフォーム戦略に従来の VM を含めることができます。ぜひご連絡いただき、費用負担のない適合性評価についてご確認ください。お客さまの重要な VM を新たに活用するための支援をいたします。

Google Cloud によって Anthos にもたらされる優れたイノベーションの詳細については、Google Cloud Next ‘22 でご確認いただけます。日程をご確認いただき、ぜひご参加ください。

- Anthos プロダクトマネージャー Amr Abdelrazik
- アウトバウンドプロダクトマネージャー Dave Bartoletti

ArgoCD を使用して GKE クラスタのフリートを構築する

Wed, 31 Aug 2022 05:00:00 +0000

※この投稿は米国時間 2022 年 8 月 31 日に、Google Cloud blog に投稿されたものの抄訳です。

アプリケーションをコンテナ化して Kubernetes 上で実行している組織はしばしば、単一クラスタを実行するだけではニーズを満たせないという状況に直面します。一例として、アプリケーションを新しいリージョンの市場にいるユーザーに近い場所で実行したいとします。新しいリージョンにクラスタを追加すれば、復元性を向上させることができます。この場合のメリットやデメリットについて詳しく知りたい方は、こちらのマルチクラスタのユースケースについての概要をお読みください。

ArgoCD とフリートを使用すると、個々のクラスタではなくクラスタのプロファイルに注目する、簡単に変更できるラベルに基づいてクラスタの状態を定義できるようになるため、マルチクラスタ環境の管理が容易になります。

この投稿では、ArgoCD と Argo Rollouts を使用して GKE クラスタのフリートの状態を自動で管理する方法を説明します。このデモでは、クラスタオペレータが経験しうる 3 つの状況について取り上げます。

クラスタをデプロイして特別なラベルを付与することに加えて、新しいアプリケーションクラスタをフリートにゼロタッチで追加します。新しいクラスタは、そのクラスタラベルに結び付けられているアプリケーションとともに、ツールとセキュリティのための一連のベースライン構成を自動的にインストールします。
新しいアプリケーションをフリートにデプロイします。フリートは、アプリケーションを開発および配信するチームのためにマルチテナントのベースライン構成を継承し、Kubernetes RBAC ポリシーをチームの ID グループに適用します。
新しいバージョンのアプリケーションをクラスタのグループ（またはウェーブ）全体に段階的にロールアウトします。各ウェーブ間では、手動の承認が必要になります。

このデモで使用されているコードは、GitHub にあります。

ArgoCD フリートアーキテクチャを構成する

ArgoCD は、Kubernetes 向けの GitOps 継続的デリバリーを提供する CNCF ツールです。ArgoCD の機能のうち、最も価値あるものの一つがその UX / UI です。クラスタのフリート全体で UI / UX を維持するには、ハブアンドスポークアーキテクチャを使用してください。ハブアンドスポークの設計では、一元化された GKE クラスタを使用して ArgoCD をホストします（ArgoCD クラスタ）。アプリケーションを Secret としてホストする各 GKE クラスタを、ArgoCD クラスタの ArgoCD Namespace に追加します。各アプリケーションクラスタに特別なラベルを割り当てて、特定できるようにします。フリートに必要な Kubernetes の構成を含む各 Git リポジトリに対して、ArgoCD 構成リポジトリオブジェクトが作成されます。ArgoCD の同期エージェントは ArgoCD アプリケーションで定義された構成リポジトリを継続的に監視します。そして、ArgoCD Namespace のクラスタの Secret に含まれるクラスタラベルに基づいて、アプリケーションクラスタのフリート全体で変更を有効にします。

基盤となるインフラストラクチャのセットアップ

アプリケーションクラスタを使用し始める前に、いくらかの基盤となるインフラストラクチャが必要になります。Fleet infra setup の手順に沿って、Google が提供するデモツールを使用し、VPC、リージョンのサブネット、Pod とサービスの IP アドレス範囲、その他の基盤となるインフラストラクチャをセットアップします。これらの手順によって、コントロールクラスタとして動作する一元化された ArgoCD クラスタも作成されます。

ArgoCD クラスタを構成する

インフラストラクチャのセットアップができたら、マネージド Anthos Service Mesh（ASM）、マルチクラスタ Ingress（MCI）、その他のコントロール用コンポーネントを使用して、一元化された ArgoCD を構成できます。まずは、フリートにとって ASM と MCI が非常に重要である理由を考えましょう。

MCI によって、クライアントに最も近いフリート内の GKE クラスタにトラフィックをルーティングするグローバルレイヤ 7 ロードバランサの前に単一のエニーキャスト IP が提供されるため、外部のクライアントからクラスタにルーティングされるすべてのトラフィックのパフォーマンスが向上します。また MCI では、リージョンの障害に対する復元性ももたらされます。クライアントに最も近いリージョンでアプリケーションに到達できない場合は、その次に近いリージョンにルーティングされます。

mTLS、アプリリケーションのレイヤ 7 の指標、その他のいくつかの優れた機能に加えて、ASM は GKE クラスタのフリート全体で Pod 間トラフィックを処理するネットワークを提供します。これは、ローカルの呼び出しが失敗するかエンドポイントがない場合に、アプリケーションが、クラスタ内の他のアプリケーションへの呼び出しを自動的に他のクラスタへリダイレクトするということを意味しています。

Fleet cluster setup の手順に沿って操作します。コマンドによって、ArgoCD のインストール、アプリケーションクラスタのツールと構成のための ApplicationSets の作成、ArgoCD へのログインを行うスクリプトが実行されます。また、GitHub のプライベートリポジトリと同期するように ArgoCD が構成されます。

GKE アプリケーションクラスタを Secret として ArgoCD Namespace に追加して `env: "multi-cluster-controller"` というラベルを付与すると、multi-cluster-controller ApplicationSet が multi-cluster-controllers フォルダ内のサブディレクトリとファイルに基づいてアプリケーションを生成します。このデモでは、そのフォルダには、各アプリケーションクラスタにインストールされる ASM Ingress ゲートウェイに対してマルチクラスタ Ingress を設定するために必要なすべての構成が含まれています。

GKE アプリケーションクラスタを Secret として ArgoCD Namespace に追加し、`env: "prod"` というラベルを付与すると、app-clusters-tooling アプリケーションセットは app-clusters-config フォルダ内の各サブフォルダに対してアプリケーションを生成します。このデモでは、app-clusters-config フォルダには各アプリケーションクラスタに必要なツールが含まれています。たとえば、argo-rollouts フォルダには、すべてのアプリケーションクラスタにインストールされる必要がある、Argo Rollouts カスタムリソース定義が含まれています。

この時点で、以下が揃っているはずです。

GitHub リポジトリと同期する、一元化された ArgoCD クラスタ。
ArgoCD クラスタと同期する、マルチクラスタ Ingress とマルチクラスタサービスオブジェクト。
各アプリケーションクラスタに対して Google Cloud ロードバランサを構成する、マルチクラスタ Ingress とマルチクラスタサービスコントローラ。ロードバランサは、最初のアプリケーションクラスタがフリートに追加されたときにのみインストールされます。
フリート全体で Istio エンドポイントとオブジェクトを監視し、Istio サイドカーとゲートウェイオブジェクトを最新の状態に維持する、マネージド Anthos Service Mesh。

次の図はこの状態を示しています。

アプリケーションクラスタをフリートに接続する

ArgoCD コントロールクラスタのセットアップができたら、新しいクラスタを作成してフリートにプロモートできます。これらのクラスタがアプリケーションを実行します。前の手順で、マルチクラスタ Ingress と Anthos Service Mesh を使用して、マルチクラスタネットワークを構成しました。新しいクラスタを、`env=prod` ラベルを使用して Secret として ArgoCD クラスタに追加することで、新しいクラスタは Anthos Service Mesh ゲートウェイなどの必要なベースラインツールを確実に自動で取得するようになります。

新しいクラスタを ArgoCD に追加するために、Secret をコントロールクラスタの ArgoCD Namespace に追加します。これは次の方法で行うことができます。

`argocli add cluster` コマンド。新しいアプリケーションクラスタに対する `clusteradmin` アクセス許可をコントロールクラスタに付与する署名なしトークンを自動的に Secret に挿入します。
Connect ゲートウェイとフリートの Workload Identity。ApplicationSets に何をすべきかを伝えるラベルなどのカスタムラベルを持つ Secret を構築し、Google OAuth2 トークンを使用して GKE コントロールプレーンに対して認証された API 呼び出しを行うように ArgoCD を構成します。

新しいクラスタを ArgoCD に追加する場合、そのクラスタを特定のロールアウトウェーブの一部としてマークできます。デモの後半で段階的ロールアウトを開始する際に、これを活用します。

次の Secret マニフェストのサンプルは、Connect ゲートウェイの認証構成と、`env: prod` および `wave` などのラベルを示しています。

デモでは、Google が提供するスクリプトを使用して、アプリケーションクラスタを ArgoCD 構成に追加できます。手順については、Promoting Application Clusters to the Fleet を参照してください。

次のサンプル画像に示されているように、ArgoCD ウェブインターフェースを使用して、クラスタ内での自動化されたツールセットアップの進捗状況を確認できます。

新しいチームアプリケーションと新しいクラスタを追加する

この時点で、フリート内のアプリケーションクラスタは、アプリケーションを提供する準備ができています。クラスタにアプリケーションをデプロイするために、アプリケーション構成を作成して、それらを ArgoCD 構成リポジトリに push します。ArgoCD は push を検出し、自動的にアプリケーションのデプロイと構成を行い、Anthos Service Mesh ゲートウェイを介してトラフィックの提供を開始します。

このデモでは、Google が提供するスクリプトを実行して、新しい ArgoCD Team にあるテンプレート `team-2` に基づいて新しいアプリケーションを作成します。手順については、Creating a new app from the app template を参照してください。

新しいアプリケーションを作成すると、段階的ロールアウトの各ウェーブに対して、そのウェーブの Git ブランチと同期されるアプリケーションセットが構成されます。

そのアプリケーションクラスタは wave one としてラベル付けされており、これまでにデプロイされている唯一のアプリケーションクラスタであるため、次のように、アプリケーションの UI には Argo アプリケーションが 1 つだけ表示されているはずです。

エンドポイントに対して `curl` を実行すると、アプリケーションは、実行されている Google Cloud ゾーンの名前を含むいくつかのメタデータを返します。

可用性を高めるために、別の Google Cloud ゾーンに新しいアプリケーションクラスタを追加できます。そのためには、同じ VPC 内でクラスタを作成し、既存の ApplicationSets に一致するラベルを持つ新しい ArgoCD Secret を追加します。

このデモでは、Google が提供するスクリプトを使用して次のことを行うことができます。

別のゾーンで新しいクラスタを追加する
新しいクラスタに、wave two というラベルを付ける（既存のアプリケーションクラスタのラベルは wave one）
ArgoCD がベースラインツールをインストールするように、アプリケーション固有のラベルを追加する
そのクラスタにサンプルアプリケーションの他のインスタンスをデプロイする

手順については、Add another application cluster to the Fleet を参照してください。スクリプトを実行した後、ArgoCD ウェブインターフェースで新しいクラスタとアプリケーションインスタンスを確認できます。インターフェースは次のようになっているはずです。

アプリケーションエンドポイントに対して `curl` を実行すると、curl の送信元からの潜在経路が最小の GKE クラスタがレスポンスを返します。たとえば、`us-west1` の Compute Engine インスタンスから curl を実行すると、`gke-std-west02` クラスタにルーティングされます。

異なる地理的位置にあるマシンからエンドポイントにアクセスしてみることにより、レイテンシベースのルーティングを実験してみることができます。

デモのこの時点では、以下がある状態です。

wave one とラベル付けされた 1 つのアプリケーションクラスタ
wave two とラベル付けされた 1 つのアプリケーションクラスタ
両方のアプリケーションクラスタにデプロイされたアプリケーションを持つ、単一のチーム
ArgoCD を使用するコントロールクラスタ
新しい変更を自動で push する、背後の構成リポジトリ

フリート全体でアプリケーションを段階的にロールアウトする

ArgoCD のロールアウトは Kubernetes のデプロイと似ていますが、ロールアウトを制御するためのいくつかの追加のフィールドがあります。新しいバージョンを `wave-1` Git ブランチから `wave-2` Git ブランチにマージし、その後 `main` にマージすることで、ロールアウトを使用してアプリの新しいバージョンをフリート全体で段階的にデプロイし、ロールアウトのウェーブごとの進捗状況を手動で承認できます。

このデモでは、Google が提供するスクリプトを使用して次のことを行うことができます。

新しいアプリケーションを、両方のアプリケーションクラスタに追加する。
アプリケーションの新しいイメージバージョンを、wave one クラスタにリリースする。
新しいアプリケーションイメージを使用する Pod から少しずつトラフィックを提供することで、ロールアウトしたバージョンにエラーがないかをテストする。
ロールアウトしたバージョンを wave two クラスタにプロモートする。
ロールアウトしたバージョンをテストする。
`main` で、ロールアウトしたバージョンを新しい stable バージョンとしてプロモートする。

手順については、Rolling out a new version of an app を参照してください。

次のサンプルは、ArgoCD ロールアウトに特有のフィールドを示しています。`strategy` フィールドは、使用するロールアウト方法を定義します。この例では、方法はカナリアで、ロールアウトには 2 つの手順が含まれます。アプリケーションクラスタのロールアウトコントローラは、ロールアウトオブジェクトに対するイメージの変更を確認して、新しいイメージを追加する際に、更新されたイメージタグを持つ新しいレプリカセットを作成します。その後ロールアウトコントローラは、クラスタへのトラフィックの 20% が新しいイメージを使用する Pod にルーティングされるように、Istio 仮想サービスの重み付けを調整します。

各手順は 4 分間実行され、次の手順に移る前に分析テンプレートを呼び出します。次の分析テンプレートのサンプルは Prometheus プロバイダを使用してクエリを実行し、ロールアウトのカナリアバージョンの成功率を確認します。成功率が 95% 以上の場合、ロールアウトは次の手順に移ります。成功率が 95% 未満の場合、ロールアウトコントローラは、stable バージョンのイメージを実行している Pod に対して Istio 仮想サービスの重み付けを 100% に設定することで、変更をロールバックします。

すべての分析手順が完了したら、ロールアウトコントローラは新しいアプリケーションのデプロイに stable というラベルを付け、その stable バージョンに Istio 仮想サービス 100% を設定し、以前のイメージバージョンデプロイを削除します。

まとめ

この投稿では、ArgoCD と Argo Rollouts を使用して GKE クラスタのフリートの状態を自動で管理する方法を学びました。この自動化によって GKE クラスタの独自性が抽象化され、時間とともに変化するニーズに合わせて、クラスタのプロモートと削除を行えるようになります。

このデモを構築するために使用されているサービスを詳しく知りたい場合は、次のドキュメントをご覧ください。

Argo ApplicationSet コントローラ: 改善されたマルチクラスタおよびマルチテナントサポート。
Argo Rollouts: Blue / Green やテストなどの高度なロールアウト機能を提供する、Kubernetes コントローラ。
マルチクラスタ Ingress: 複数の GKE クラスタを単一の Google Cloud ロードバランサにマッピングし、1 つのクラスタを Ingress コントローラのコントロールポイントとして使用します。
マネージド Anthos Service Mesh: 高可用性のために、アプリケーションをフリート内の複数のクラスタ全体に分散させる機能を持つ、一元化された Google マネージドコントロールプレーン。
フリートの Workload Identity: フリートのクラスタの任意の場所にあるアプリケーションが、Kubernetes サービスアカウントを IAM サービスアカウントとして使用して Google Cloud API に認証できるようにします。サービスアカウントキーや他の長期間の認証情報の管理は必要ありません。

Connect ゲートウェイ: VPN、VPC ピアリング、SSH トンネルを必要とすることなく、Google ID プロバイダを使用してクラスタに対する認証を行います。

- GKE プロダクトマネージャー Nicholas Eberts
- GKE テクニカルライター Shannon Kularathna

Anthos Service Mesh を使用して Google 社員のためにアプリを保護する

Wed, 24 Aug 2022 04:00:00 +0000

※この投稿は米国時間 2022 年 8 月 13 日に、Google Cloud blog に投稿されたものの抄訳です。

皆様こんにちは。アクセスサイト信頼性エンジニアリング（SRE）の David Challoner です。ここではデベロッパーリレーションズの Anthony Bushong と一緒に、コーポレートエンジニアリングがどのように Anthos Service Mesh を Google 社内に導入しているかご説明します。

コーポレートエンジニアリングは、Google の「エンタープライズ IT」を担当しています。コーポレートエンジニアリングの重要な任務は、法務、財務、フロアプラン、さらには社内カフェのメニューを考案するアプリといった、社内のビジネスプロセスの基盤となる、自社ソフトウェアとサードパーティソフトウェアを実行することです。これらのプロセスはすべて、Google 製アプリケーションと同一のセキュリティ基準と制作基準を遵守しています。

Google 社員は、こうしたアプリケーションだけでなく、他のアプリケーションや Google Cloud サービスへのアクセスが必要になる場合があります。このトラフィックはさまざまな信頼境界を横断し、それによって異なるポリシーがトリガーされることがあります。

アクセス SRE はこのアクセスを仲介するシステムを実行し、Google は、社員がこうしたアプリケーションにアクセスする方法を保護するソリューションの一部として、Anthos Service Mesh を実装しています。

なぜでしょうか？

お分かりかもしれませんが、コーポレートエンジニアリングが担当するアプリケーションには別の要件があります。これは多くの場合、特定のアプリケーションが、法務上、業務上、技術上の事由により、別のインフラストラクチャに依存することを意味します。インフラストラクチャごとに動作や機能が異なる場合、アプリケーションの使用は容易ではありません。

そこで Anthos の出番です。Google Cloud は、このように多様な基盤インフラストラクチャ上でアプリを使用する環境を統合する、一貫したプラットフォームインターフェースを提供するため、Kubernetes API を基盤として Anthos を構築しました。

コーポレートエンジニアリングサービスへのアクセスを仲介する一般的な認可フレームワークの構築に適したツールとして、Google は Anthos を利用することにしました。特に、オープンソースプロジェクト Istio の機能を利用している Anthos Service Mesh が適しています。サービスのデプロイ先が Google Cloud、コーポレートエンジニアリングのデータセンター、実際の Google キャンパスのエッジのどれであっても、Anthos Service Mesh は安全な接続をプログラミングするため、Google に一貫した方法を提供してきました。

ASM が社内組織に及ぼす効果を明らかにするため、この ASM を管理して使用する担当者のロールをご紹介します。

図 1 - Anthos Service Mesh はさまざまなロールを担う複数の担当者間でサービスを安全に接続

セキュリティ関係者に対しては、ASM はワークロードの ID に基づいた証明書のプロビジョニングと、きめ細かいアプリケーション対応アクセス制御の適用が可能なアプリケーションごとに実行される、拡張可能なポリシー適用ポイントを提供します。

プラットフォームオペレーターに対しては、ASM は、すぐに使えるリリースチャネル、メンテナンスの時間枠、公開済みのサービスレベル目標（SLO）を提供することで運用上のオーバーヘッドを削減できるマネージドプロダクトとして提供されます。

サービスオーナーに対しては、ASM はネットワークの問題からアプリケーションを切り離し、一方で、レート制限、負荷制限、リクエストのトレースとモニタリングなども提供します。このような機能は通常、Kubernetes の作成に役立つ自社のクラスタマネージャーである Borg で実行されたアプリケーションでのみ使用できます。

まとめると、運用上のオーバーヘッドを最小限に抑えて、膨大な数の多様なサービスへのアクセスを保護すると同時に、サービスオーナーにはきめ細かいトラフィック制御を提供します。

実際にどのようになっているか下図で見ていきましょう。

アーキテクチャ

図 2 - コーポレートエンジニアリングサービスと Anthos のアーキテクチャの概要

このフローでは、ユーザーのアクセスは最初に Identity Aware Proxy（IAP）と Cloud Armor を使用して構成された Google Cloud グローバルロードバランサに到達します [1]。IAP は BeyondCorp に関する Google 社内の理念の実装を一般公開したものです。BeyondCorp は、VPN を使用しなくても、信頼できないネットワークでも機能する認証レイヤを提供します。

ユーザーが認証されると、リクエストは Anthos Service Mesh から提供される Ingress Gateway に流れます [2]。これにより、リクエストが IAP を介して発生する場合のみ、トラフィックがサービスに流れるかを確認するための追加のチェックが提供されます。同時に、Anthos Service Mesh Gateway とさまざまなチームが所有するコーポレートサービスとの間に相互 TLS（mTLS）も提供されます。

最終的に、各 Service Pod で実行されるサイドカーによって追加のポリシーが適用されます [3]。ポリシーは Anthos Config Management を使用してソース管理から取得され [4]、Anthos Service Mesh が提供するマネージドコントロールプレーンによってすべてのサイドカーに反映されます [5]。

メッシュの管理

Istio の仕組みに不慣れな場合は、コントロールプレーンとデータプレーンのパターンが踏襲されます。データプレーンは、以前少しご説明したとおり、Google のすべての Service Pod とともに稼働するサイドカーコンテナで構成されています。一方コントロールプレーンは、Google が適用を希望するポリシーを使用して、サイドカーの更新を行います。

図 3 - Istio のアーキテクチャの概要

そのため、コントロールプレーンを正常に保つことが Google にとって非常に重要です。フルマネージドのコントロールプレーンに対する Anthos Service Mesh のサポートに関して、Google のプラットフォームオーナーに多大なメリットをもたらすからです。他の多くの企業と同様、Google 社内の組織がクラウドリソースをプロビジョニングする場合には、コードプロジェクトとして一般的なオープンソースインフラストラクチャの Terraform を使用します。宣言型の使いやすい方法で、Anthos Service Mesh コントロールプレーンをプロビジョニングできます。

最初に Terraform を使用して下記の google_gke_hub_feature リソースを作成し、GKE 用のマネージドコントロールプレーン機能を有効にします。

code_block: <ListValue: [StructValue([('code', 'resource "google_gke_hub_feature" "feature_asm" {\r\n name = "servicemesh"\r\n location = "global"\r\n provider = google-beta\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fee6827b9d0>)])]>

リソースを公開する際は、Terraform の google-beta プロバイダからでないと利用できませんのでご注意ください。

リソースが作成されたら、ControlPlaneRevision カスタムリソースを GKE クラスタにプロビジョニングして、このクラスタに ASM 用のマネージドコントロールプレーンをスピンアップします。

code_block: <ListValue: [StructValue([('code', 'apiVersion: mesh.cloud.google.com/v1alpha1\r\nkind: ControlPlaneRevision\r\nmetadata:\r\n name: asm-managed\r\n namespace: istio-system\r\nspec:\r\n type: managed_service\r\n channel: regular'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fee6827b1c0>)])]>

このカスタムリソースを使用すると、ASM マネージドコントロールプレーン用にリリースチャネルを設定できます。これで、Google のプラットフォームチームがそのニーズに対応したアップグレードのペースを定義できるようになります。

ASM はコントロールプレーンの管理に加え、データプレーンに関する管理機能も提供するので、各サイドカー Envoy は最新のセキュリティ更新が適用された状態を保ち、コントロールプレーンとの互換性も維持できます。これでサービスオペレーターの心配事が 1 つ減ります。適切なバージョンのサイドカープロキシを挿入するように Google の Pod ワークロード定義を変更するには、Kubernetes の変更用アドミッション Webhook と Namespace ラベルを使用します。

必須のアクセスポリシーの同期

Google のセキュリティ担当者は Anthos Service Mesh の主要コンポーネントが用意された状態で Istio API を使用して、一貫性のある必須のセキュリティポリシーを GKE クラスタごとに定義できます。

たとえば、あるポリシーが、自動的にプロビジョニングされる Workload Identity 証明書を使用して Pod 間に厳格な mTLS を適用しているとします。先ほど Istio Gateway 間でこれがどのように適用されるかご説明したように、同じポリシーが Google のクラスタのすべての Pod 間の mTLS に適用されます。

図 4 - 相互 TLS の概要図

Google が実装するもう 1 つのポリシーは、すべての下り（外向き）トラフィックをデフォルトで拒否するものです。この実装には、サービスチームがそのアウトバウンド依存関係を明示的に宣言する必要があります。次の例では、Istio サービスエントリを使用して、特定の外部サービス（ここでは Google）へのきめ細かいアクセスを許可しています。これは外部サービスへの意図しないアクセスを防ぐうえで有効です。

code_block: <ListValue: [StructValue([('code', 'apiVersion: networking.istio.io/v1alpha3\r\nkind: ServiceEntry\r\nmetadata:\r\n name: google\r\nspec:\r\n hosts:\r\n - www.google.com\r\n ports:\r\n - number: 443\r\n name: https\r\n protocol: HTTPS\r\n resolution: DNS\r\n location: MESH_EXTERNAL\r\nEOF'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fee6827ba00>)])]>

これらのポリシーは Anthos Config Management を使用して、各クラスタのすべてのサービスメッシュ名前空間と自動的に同期されます。Anthos Config Management は Google 社内のソース管理システムを信頼できるソースとして使用することで、Google の GKE クラスタすべてにわたってポリシーの同期と調整が可能になり、Google のサービスごとにこれらのポリシーが確実に設定されます。Anthos Config Management に関する Google の実装について詳しくは、こちらをご覧ください。

これが行われると、Google のチームは最終的に、明示的な IP、ポート、プロトコルのポリシーに基づいて単独で動作するセキュリティの自動化からの移行に着手します。

Identity-Aware Proxy とのインテグレーション

コーポレートエンジニアリングが使用する BeyondCorp プロキシの一般公開バージョンは Identity-aware Proxy（IAP）と呼ばれ、Anthos Service Mesh とのインテグレーションを提供します。IAP を利用することで、ユーザーは Google のサービスへのアクセスが認証され、コンテキストアウェアアクセスポリシーを適用できるようになります。このインテグレーションには次の 2 つのメリットがあります。

サービスメッシュでのサービスへのユーザートラフィックを Identity-aware Proxy 経由のみにする
Google が収集する複数のデバイスシグナルで定義されるデバイスにコンテキストアウェアアクセス（CAA）信頼レベルを適用する

Identity-aware Proxy を使用することで、Request Context Token（RCToken）でこの情報をキャプチャできるようになります。RCToken は、ASM によって検証できる Identity-aware Proxy が作成する JSON Web Token（JWT）です。IAP はこの JWT を Ingress-Authorization ヘッダーに挿入します。次のポリシーに類似した Istio 認可ポリシーを使用する場合、この JWT のないリクエストはすべて却下されます。

code_block: <ListValue: [StructValue([('code', 'apiVersion: security.istio.io/v1beta1\r\n kind: AuthorizationPolicy\r\n metadata:\r\n name: iap-gateway-require-jwt\r\n namespace: istio-system\r\n spec:\r\n selector:\r\n matchLabels:\r\n app: istio-iap-ingressgateway\r\n action: DENY\r\n rules:\r\n - from:\r\n - source:\r\n\tnotRequestPrincipals: ["*"]'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fee6827beb0>)])]>

次のポリシーの例は、fullyTrustedDevice アクセスレベルを必要としています。これは、会社所有で、完全に更新され、IT が承認した構成を実行していることが確認されている、組織のデバイスなどが該当します。

code_block: <ListValue: [StructValue([('code', 'apiVersion: security.istio.io/v1beta1\r\nkind: AuthorizationPolicy\r\nmetadata:\r\n name: require-fully-trusted-device\r\n namespace: fooService\r\nspec:\r\n selector:\r\n matchLabels:\r\n app: fooService\r\n action: ALLOW\r\n rules:\r\n - from:\r\n - source:\r\n requestPrincipals: ["*"]\r\n when:\r\n - key: request.auth.claims[google.access_levels]\r\n values: ["accessPolicies/$orgId/accessLevels/fullyTrustedDevice"]'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fee6827bf70>)])]>

このポリシーによって、Google のセキュリティチームは、サービス間通信やサービスからのアウトバウンド呼び出しを保護すると同時に、信頼できるデバイスと、信頼できるデバイスを使用する認証済みユーザーからの受信リクエストが特に必要になります。

サービスチームを有効にする

SRE としての Google の優先事項の一つは、サービスレベル指標（SLI）、SLO、サービスレベル契約（SLA）がサービスに対応して存在するかを確認することです。Anthos Service Mesh では、メッシュ内のすべてのサービスに対するレイテンシや可用性などの水平リクエスト指標を公開するため、サービスオーナーはこれを自分たちのサービスに対して実行できます。

Anthos Service Mesh を利用する前に、各アプリケーションはこれらの指標を別個にエクスポートしておく必要があります（存在する場合）。ASM を利用することで、サービスオーナーは水平にエクスポートされた指標を使用して、サービスの SLO をクラウドコンソールに、または Terraform 経由で、簡単に定義できるようになります。続いて SLO を Google のより高度なサービス定義に統合し、Google が SLO モニタリングとアラートをデフォルトで利用できるようにします。SRE ブックで SLO とエラーバジェットの詳細をご覧ください。

重要なポイント

ASM は、企業が自社の IT インフラストラクチャをモダナイズするために使用できる便利なツールです。次の機能を提供します。

環境に依存しない共有適用ポイントでセキュリティポリシーを管理
統一的な方法で ID をプロビジョニングし、アプリケーションの依存関係を記述

分散トレースや段階的カナリヤロールアウトなど、これまでにない運用能力も実現されます。これらは、一般的な企業のアプリケーション環境ではほとんど見られないものです。

既存の認可システムで、ギャップの解消に向けて段階的に導入、普及できるので、導入への障壁が低く、今すぐ評価を開始することをおすすめします。

- サイト信頼性エンジニア David Challoner
- デベロッパーリレーションズエンジニア Anthony Bushong

スケールアウトコンピューティングクラスを使用した、GKE Autopilot への高スループットワークロードのデプロイ

Mon, 01 Aug 2022 08:50:00 +0000

※この投稿は米国時間 2022 年 7 月 20 日に、Google Cloud blog に投稿されたものの抄訳です。

GKE Autopilot は多機能のフルマネージド Kubernetes プラットフォームで、Kubernetes API をフル活用しており、クラスタの管理と運用に操作不要方式を採用しています。Autopilot を昨年リリースして以来、ワークロードの需要に応えるべく、イノベーションと機能の追加を継続してきました。このたび、Autopilot にコンピューティングクラスの概念が導入され、x86 と Arm の高パフォーマンスコンピューティングを実現するスケールアウトコンピューティングクラスがプレビュー版になったことをお知らせします。

Autopilot コンピューティングクラスはワークロードのデプロイが可能なハードウェア構成を厳選したものです。今回の初回リリースでは、スケールアウトコンピューティングクラスを導入しました。これは、コアあたり 1 スレッドに最適化されたワークロード向けに設計されており、水平方向にスケールします。スケールアウトコンピューティングクラスでは現在、x86 と Arm の 2 つのハードウェアアーキテクチャをサポートしています。自社ワークロードの価格とパフォーマンスのバランスに適した方を選択できます。スケールアウトコンピューティングクラスは Google Cloud の既存の汎用コンピューティングオプションに加わり、Google Cloud で利用可能な最速の CPU プラットフォームを活用する形でワークロードを実行するように設計されています。また、CPU 使用率が高いアプリケーションにおいて高い費用対効果を実現します。

一部のワークロードはよりパフォーマンスの高いコンピューティングからメリットが得られるとの声もいただいています。こうしたニーズに応えるために、スケールアウトコンピューティングクラス上で実行される x86 ワークロードは現在、第 3 世代の AMD EPYC^TM プロセッサによって提供されており、同時マルチスレッディング（SMT）を無効化することで、Google Cloud の x86 プラットフォームのなかで最高のコア単位ベンチマークを達成しています。

また、今回初めて Autopilot が Arm ワークロードをサポートするようになりました。現在は、Ampere® Altra® の Arm ベースプロセッサ上で実行している新しい Tau T2A VM を利用することで、スケールアウトコンピューティングクラスには、特定のプラットフォームに依存しない活発でオープンなエンドツーエンドのエコシステムに加え、Arm ワークロードのコストパフォーマンスのメリットがあります。Autopilot Arm Pod は現在、us-central、europe-west4、asia-southeast1 で利用できます。

スケールアウトコンピューティングクラスを使用した Arm ワークロードのデプロイ

Pod を特定のコンピューティングクラスと CPU にデプロイするには、デプロイ仕様に次のラベルを指定して、Kubernetes の nodeSelector かノードアフィニティルールを追加します。

cloud.google.com/COMPUTE-CLASS
kubernetes.io/ARCH

Autopilot で Arm ワークロードを実行するには、いずれかのサポート対象リージョンでバージョン 1.24.1-gke.1400 以降を実行しているクラスタが必要です。このバージョンで新しいクラスタを作成することも、既存のバージョンをアップグレードすることもできます。新しい Arm 対応クラスタを CLI で作成するには、以下を使用します。

code_block: <ListValue: [StructValue([('code', 'CLUSTER_NAME=autopilot-arm\r\nREGION=us-central1\r\nVERSION=1.24.1-gke.1400\r\ngcloud container clusters create-auto $CLUSTER_NAME \\\r\n --release-channel "rapid" --region $REGION \\\r\n --cluster-version $VERSION'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fee427fd910>)])]>

たとえば、次の Deployment 仕様は Nginx 公式イメージを Arm アーキテクチャでデプロイします。

code_block: <ListValue: [StructValue([('code', 'apiVersion: apps/v1\r\nkind: Deployment\r\nmetadata:\r\n name: nginx-arm64\r\nspec:\r\n selector:\r\n matchLabels:\r\n app: nginx\r\n template:\r\n metadata:\r\n labels:\r\n app: nginx\r\n spec:\r\n nodeSelector:\r\n cloud.google.com/compute-class: Scale-Out\r\n kubernetes.io/arch: arm64\r\n containers:\r\n - name: nginx\r\n image: nginx:latest'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fee427fd5b0>)])]>

スケールアウトコンピューティングクラスへの x86 ワークロードのデプロイ

スケールアウトコンピューティングクラスでも、「スケールアウト」コンピューティングクラス用のセレクタを追加することで、x86 アーキテクチャをサポートしています。kubernetes.io/arch: amd64 でアーキテクチャを明示的に設定できます。x86 がデフォルトであるため、セレクタからこのラベルを省略することもできます。

Autopilot で x86 スケールアウトワークロードを実行するには、いずれかのサポート対象リージョンでバージョン 1.24.1-gke.1400 以降を実行しているクラスタが必要です。上記のサンプルの同じ CLI コマンドで、x86 Scale-Out-capable GKE Autopilot クラスタを取得します。

code_block: <ListValue: [StructValue([('code', 'apiVersion: apps/v1\r\nkind: Deployment\r\nmetadata:\r\n name: nginx-arm64\r\nspec:\r\n selector:\r\n matchLabels:\r\n app: nginx\r\n template:\r\n metadata:\r\n labels:\r\n app: nginx\r\n spec:\r\n nodeSelector:\r\n cloud.google.com/compute-class: Scale-Out\r\n containers:\r\n - name: nginx\r\n image: nginx:latest'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fee427fda30>)])]>

スケールアウトコンピューティングクラスを使用した Spot Pod のデプロイ

ラベル cloud.google.com/gke-spot: “true” を nodeSelector に追加することで、コンピューティングクラスと Spot Pod を結合することもできます。

code_block: <ListValue: [StructValue([('code', 'apiVersion: apps/v1\r\nkind: Deployment\r\nmetadata:\r\n name: nginx-arm64\r\nspec:\r\n selector:\r\n matchLabels:\r\n app: nginx\r\n template:\r\n metadata:\r\n labels:\r\n app: nginx\r\n spec:\r\n nodeSelector:\r\n cloud.google.com/gke-spot: "true"\r\n cloud.google.com/compute-class: Scale-Out\r\n kubernetes.io/arch: arm64\r\n containers:\r\n - name: nginx\r\n image: nginx:latest'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fee427fdfd0>)])]>

スケールアウトコンピューティングクラスを使用する場合は、x86 と Arm 両方のアーキテクチャで Spot Pod がサポートされます。

スケールアウトコンピューティングクラスを GKE Autopilot でぜひお試しください。

詳細については、Autopilot クラスタの作成、コンピューティングクラスの概要、Arm ワークロード用イメージの構築、GKE Autopilot への Arm ワークロードのデプロイに関するガイドをご覧ください。

- Google Kubernetes Engine、GKE Autopilot プロダクトマネージャー William Denniss

- プロダクトマネージャー Gari Singh

Anthos オンプレミスとベアメタル版 Anthos をベースにする Google Distributed Cloud Virtual

Fri, 24 Jun 2022 01:00:00 +0000

※この投稿は米国時間 2022 年 6 月 17 日に、Google Cloud blog に投稿されたものの抄訳です。

Google は昨年、Google のインフラストラクチャをエッジとデータセンター内に提供する、ハードウェア、ソフトウェア、サービスのポートフォリオ Google Distributed Cloud（GDC）を発表しました。3 月には、Google Distributed Cloud Edge が一般提供となり、新しい通信エッジワークロードとエンタープライズエッジワークロード向けの、ハードウェアおよびソフトウェア統合ソリューションが利用可能になりました。そして本日ご紹介するのは、Google Distributed Cloud Virtual です。ソフトウェアとサービスのみのソリューションであり、統合された新しいプロダクトファミリーとしての GDC ポートフォリオに、既存の（VMware vSphere とベアメタル版 Anthos のサービス向け）Anthos オンプレミスが加わりました。

Anthos オンプレミス（新名称「GDC Virtual」）をご利用のお客様には、今まで通りの一貫した管理とデベロッパーエクスペリエンスが提供されます。現在の機能や料金構成、ユーザーインターフェース全体の外観は変わりません。また、一貫した追加ロードマップを今後もご利用いただけます。GDC Virtual をこれからご利用されるお客様にとっては、その機能は、（クラウドへの移行を加速させるよう設計されている）GDC Edge と GDC Hosted のサービスを完結させるものになるでしょう。

これらのサービスをまとめることで、Edge、Hosted、Virtual 向け Google Distributed Cloud ポートフォリオでは、どのような IT 環境を選択しても、共通の Anthos API を基盤とし、開発とセキュリティ、管理における一貫性のあるエクスペリエンスを提供します。たとえば、フォームファクタの種類をシステム全体から選択する機能があります。ソフトウェアのみのソリューションと、ハードウェアおよびソフトウェア統合ソリューションのどちらかを選ぶ、あるいはセルフマネージドと、Google や別の信頼できるパートナーによるフルマネージドのどちらかを選ぶことができます。お客様固有のビジネスとワークロードのニーズに応じて、組織に最適なシナリオを選びましょう。

クラウドで管理され、お客様のインフラストラクチャにデプロイされた GDC Virtual を使うことで、Google Cloud のソフトウェアのみの拡張が提供され、以下のことが可能になります。

お客様が選択する要件とフォームファクタで、VM 上の GKE クラスタと既存のベアメタルインフラストラクチャのプロビジョニングと管理を自動化する。また、Google Cloud コンソールを使って vSphere で Anthos クラスタをプロビジョニングする
デベロッパーが、コンテナベースのワークロードを Kubernetes に直接ビルドとデプロイができる、またはアプリケーションランタイムにビルドとデプロイができる
クラウドとオンプレミスクラスタ全体に連携セキュリティとアクセス制御、ID 管理を適用する

これらの機能についてより具体的に理解していただくため、お客様が GDC Virtual をデプロイする例を以下に示します。

あるお客様が自身が所有する VM 環境に多額の投資をしています。GDC Virtual を選択することで、既存のインフラストラクチャを活用し、モダナイズされた新しいアプリケーションを実行できます。
あるお客様が高度な AI / ML ワークロードを各店舗に提供したいと考えています。お客様の施設内でデプロイする必要があることから、フットプリントとハードウェアに関して特定の要件があります。GDC Virtual を使うことで、新しいワークロードを特定の要件を満たしたハードウェアとフットプリントにデプロイできます。
ある大手自動車メーカーがアプリケーションをクラウドに移行しようとしています。取り組みの中で、既存のオンプレミスの投資を活用しています。GDC Virtual を選ぶことで、クラウドに移行する前にアプリケーションをモダナイズできます。

GDC Virtual の導入が急速に増加

一貫性のあるクラウド運用モデルとデベロッパーエクスペリエンスを提供するため、Anthos は 3 年前に開発されました。その後、Anthos の導入は急激に増加し続けてきました。実際、2021 年から 2022 年の間に Anthos プロダクトのお客様は 5 倍以上に増えました。同じ期間で、ベアメタル版 Anthos（現在は Google GDC Virtual）のお客様は 4 倍以上になりました。お客様が Anthos を利用する方法は多様になっており、GDC Edge、Virtual、Hosted はすべて Anthos で動作します。注目すべきお客様の事例をいくつかご紹介します。

TELUS - 通信技術の大手プロバイダ TELUS は、Anthos オンプレミスの機能によって新しいマルチアクセスエッジコンピューティング（MEC）のユースケースを実現しました。この新しい通信エッジソリューションでは、トラフィックの処理と管理を一元管理型のクラウドから TELUS の 5G ネットワークのエッジに移すことで、お客様のより近くでアプリケーションをデプロイし、コンテンツを処理することが可能となり、パフォーマンス、セキュリティ、カスタマイズの向上など複数の利点が得られます。たとえば、新しい Connected Worker Safety ソリューションをさまざまな業種で利用して、安全性の向上、負傷事故の防止、人命救助に役立てられるようになります。このソリューションの詳細はこちらをご覧ください。

Major League Baseball（MLB） - MLB は米国とカナダにある 30 のチームをサポートしており、クラウドと各球場にオンプレミスのデータセンターを備えたエッジでワークロードを実行しています。Anthos を使用することで、これらのワークロードをコンテナ化し、アプリケーションにとって最適な場所でワークロードを実行することが可能となっています。特に、スタジアム内のデータをファンやブロードキャスト、あるいはスコアボードに配信するなど、レイテンシの理由から球場内でローカルコンピューティングを実現する必要があるシナリオが可能になります。これによって、MLB の 30 のチームにデータの民主化と配布を行い、分析情報とファンのエンゲージメントにかかる時間を短縮できています。

Google コーポレートエンジニアリング - Google コーポレートエンジニアリングは、Anthos で、共通のツールを使うことで、オペレーションを一貫させ、Google Cloud とオンプレミス分散型クラウド環境全体の費用を減らすことに取り組んでいます。2021 年に、Google はベアメタル版 Anthos を使って、企業のオフィスのエッジ環境で最初の本番環境ワークロードを実行し始めました。2022 年には、ホストするデータセンターに最初の本番環境ワークロードを追加しました。年末までに、Google は仮想化プラットフォームのかなりの部分を GDC Virtual に移行する計画をたてています。この最後の移行の中には、セキュリティや財務、IT などの会社のオペレーションにとって重要な多数のエンタープライズワークロードが含まれます。

Google Distributed Cloud で柔軟な選択

Google にとって、お客様の変換の要件に対応することは、オープン性と選択肢を取り入れた Google Distributed Cloud ポートフォリオを提供することです。GDC Virtual では、実績のある Anthos スタックで構築された新しい消費モデルを、インフラストラクチャ上でのソフトウェアのみのデプロイの選択肢としてお客様に提供します。これによってモダナイゼーションに取り組むことができ、自身のビジネスに適したペースで前進することができます。

GDC Virtual のこの更新によって、Google Distributed Cloud ポートフォリオでは、オンプレミスからエッジ、そしてクラウドへの一貫したオペレーションが可能になりました。

GDC Virtual の詳細については、Google Distributed Cloud のウェブサイトをご覧ください。現在 Google Cloud をご利用のお客様の場合は、Anthos Service Mesh と構成管理を GKE クラスタに追加することで、Google Distributed Cloud をご確認いただけます。

- Cloud Native Runtimes エンジニアリング担当ゼネラルマネージャー兼バイスプレジデント Chen Goldberg

Redbox が GKE と Anthos のマルチクラスタ Ingress でクラスタ間のサービスの復元力と可用性を向上させた方法

Wed, 22 Jun 2022 01:00:00 +0000

※この投稿は米国時間 2022 年 6 月 11 日に、Google Cloud blog に投稿されたものの抄訳です。

米国では、国中のさまざまな店舗で赤色の映画レンタルボックスを頻繁に目にします。この映画レンタルボックスやオンデマンドエンターテイメントを提供している企業が Redbox です。

Redbox のクラウドネイティブへの取り組みは、マイクロサービスを他社のクラウドプロバイダで 1 つのリージョンにデプロイするところから始まりました。このデプロイは、主にそのリージョン内の 1 つのコンピューティングクラスタ上で実施されました。ビジネスの需要に伴い、Redbox はマルチリージョンへのデプロイ（東部および西部）が必要であるという結論に至りました。マイクロサービスに同じアプリケーションアーキテクチャを活用しつつ、東部および西部 2 つのリージョンにそのアプリケーションをデプロイするというものです。トラフィックのほとんどは東部から送信されていましたが、西部からの送信量も増加しており、マルチリージョンソリューションを確立してお客様のトラフィックを効果的に処理することが同社にとってますます重要になっていました。この問題をどのように解決したのか、Redbox の Lin Meyer 氏にお話を伺いました。

従来のマルチクラスタソリューションで解決できなかった課題とは？

Redbox は通常、シングルリージョンアーキテクチャを使用してアプリケーション稼働率 99% を実現していましたが、マルチリージョンアプローチを採用することでこの稼働率を 99.9% に引き上げたいと考えていました。主に夜の時間帯と週末にストリーミングサービスへの需要が高まることが原因で、可用性に問題が発生していたためです。マルチリージョンやマルチクラスタのソリューションについて調査し始めたものの、すぐに既存のツールセットには重要な課題が複数存在することに気がつきました。

トラフィック管理の問題。トラフィックをクラスタ間で移行するというアプローチもありましたが、それを実行する権限の多くはオペレーター個人に委ねられていました。アプリケーションやインフラストラクチャによる利用可能なクラスタへのルーティングが失敗した場合、その環境のオペレーターがテレメトリーを使用してトラフィック管理ルールを構成することになっていました。
複雑さ。このクラウドプロバイダで当時利用できたオプションは、Redbox が求めていたマルチクラスタトポロジを実現するため、さまざまなクラウドサブシステム間（ネットワーキング、セキュリティ、コンピューティングなど）の数多くのカスタムスクリプト、エンジニアリング、構成に依存していました。

GKE、Anthos、マルチクラスタ Ingress を選んだ理由は？

特にこの可用性の問題に対処するため、Redbox は 2019 年後半からマネージド Kubernetes サービスの調査を開始しました。Kubernetes を調査して、このマルチリージョンのニーズに対応するソリューションが組み込まれているか確認しました。まず、マルチクラスタの要件を達成するより洗練された方法があるかどうかを確認するために、他のクラウドマネージドサービスを調べることから着手しました。この調査の評価に基づいて、次の 2 つの理由から現行のソリューションでは機能しないと結論付けました。

プラットフォームの構築に他のプラットフォームが必要。調査の結果、他のマネージド Kubernetes サービスでは、プラットフォームで他の機能を構築する必要があることが判明しました。たとえば、ノード自動スケーリング機能などです。対処する方法はありましたが、クラスタオペレーターによってこれらのサービスを使用してベースクラスタを構成することが想定されていました。Redbox が求めていたのは、こうしたインフラストラクチャレベルのアドオンを利用できる、もしくは簡単に有効化できるマネージドサービスだったのです。
専用マルチクラスタ / リージョンソリューションの欠如。DNS サービスを使用してこの機能を導入することも考えられましたが、DIY 要素が強く、専用のマルチクラスタソリューションでもないため、多くのエンジニアリング作業を要し、ソリューション自体も不安定なものになる可能性がありました。理想的には、より洗練された高度なマルチクラスタソリューションを求めていました。

GKE を検討し始めてすぐに、マルチクラスタ Service（MCS）とマルチクラスタ Ingress（MCI）サービスについて知り、これこそが Redbox のマルチリージョン要件を真に満たし得るものだと考えました。GKE 自体に感銘を受けたのはもちろんですが、Redbox が GKE を検討するきっかけを作った主な要因は MCI と MCS にありました。

マルチクラスタ Ingress とマルチクラスタ Service の恩恵とは？

Redbox が MCS を選択した理由はいくつかあります。

専用サービス。多くのエンジニアリング作業を必要とする他のアプローチとは異なり、このサービスはフルマネージドされたものであるため、オペレーターは業務の複雑さやエンジニアリングの労力から開放されました。DevOps チームはこの機能を有効にするために必要なサービスに集中でき、MCS および MCI の管理者はネットワーキングとロードバランシングの基盤となる部分について細かい点を担当できました。この抽象化レベルこそ、Redbox チームが探し求めていたものでした。
宣言型の構成。MCS サービスは YAML の使用をサポートしているため、Kubernetes ベースの他のアーティファクトとの連携が非常に円滑になりました。コンソール上で多くの項目を操作して更新するという作業が不要になることから、Redbox にとって望ましいアプローチでした。また、CI / CD ツールチェーンとも非常に相性が良く、構成のバージョン管理もかなり簡単なものになりました。

Redbox チームは、いくつかの API をプロジェクトレベルで有効にすることでサービスの開発を非常に迅速に進めることができ、MCS サービスを立ち上げて数日のうちにトラフィックを受け入れることができました。その翌週中にはすべてのフェイルオーバー負荷テストを完了し、2 週間ですべてを立ち上げて本番環境にデプロイできました。

図 1: Redbox のアーキテクチャの概要。NGINX バックエンドで圧縮された外部のマルチクラスタ Ingress とマルチクラスタ Service 経由で制御される上り（内向き）のマルチリージョン / マルチクラスタトポロジが示されている

このデプロイにより得られたメリットとは？

Redbox チームは本番環境でこのサービスを約 2 年間使用し続けています。これまでに実感している主なメリットは次のとおりです。

可用性。このサービスにより、アプリケーションの可用性と稼働時間が大幅に向上しました。MCS サービスを活用するだけで、Redbox サービスに対し 99.99% の可用性を実現しています。MCI サービスにより、問題発生時のクラスタ間でのフェイルオーバーがシームレスに実行されるため、エンドユーザーのアプリケーションが停止することはほぼありません。
シンプルなデプロイ。MCS サービスをネイティブの Kubernetes オブジェクトとしてサポートすることで、DevOps チームは構成デプロイの標準的なプロセスとして、マルチリージョンデプロイ用のサービスの宣言型の構成を含めることができます。
定期メンテナンス。MCS サービスを導入したことで、DevOps チームがダウンタイムなしでリージョンクラスタ上での定期メンテナンスを実行できるというメリットも得られました。たとえば、現在チームは各クラスタで Istio を実行しており、Istio をアップグレードするには基本的にクラスタのアップグレードとアプリケーションの再起動が必要です。MCS によりアプリケーションの可用性が保証され続けるため、ダウンタイムなしでメンテンス作業を実行することができます。これにより、稼働時間が大幅に増加しました。
サービス間通信。MCS により、サービス間通信用のデータパスも大幅に改善されています。現在 Redbox は、データのカテゴリ（PCI と非 PCI）ごとに分割された複数の環境を実行しています。PCI および非 PCI クラスタ用に 1 つの GKE フリートをデプロイしてから、MCS を使用してマルチリージョン方式でサービスを公開することで、MCS エンドポイントを介した PCI サービスと非 PCI サービスの通信が可能になりました。これにより、MCS がマルチクラスタ Service 用のサービスレジストリとして機能し、サービスエンドポイントの検出と呼び出しがシームレスに処理されます。また、内部または外部ロードバランサを経由することなくサービス同士が接続されることにより、さらに効率的なデータパスが提供されます。

まとめ

Redbox は、DVD の自動レンタルボックスビジネスと急速に拡大しているデジタルストリーミングサービスのニーズを満たすために、インフラストラクチャとデプロイプラットフォームのモダナイズが必要であることを認識していました。迅速かつ安全にデプロイする方法を模索するなかで、Google Kubernetes Engine に出会い、マルチクラスタ Ingress とマルチクラスタ Service の使用を選択し、複数の GCP リージョンでお客様向けアプリケーションをホストしました。GKE や MCI を活用することで、Redbox は新しい機能や製品をこれまで以上に迅速にお客様に提供しながら、クラウドへのデジタルトランスフォーメーションを継続することができています。MCI によりトラフィックは使用可能な最も近いクラスタに直ちにルーティングされるため、信頼性の向上と応答時間の短縮も実現しています。

Anthos や MCI の詳細については、https://cloud.google.com/anthos をご覧ください。

- Google Cloud カスタマーエンジニア Guna Vijayaratnam
- Redbox クラウド DevOps 担当マネージャー Lin Meyer 氏

Anthos

Banco BV が GKE と Anthos でバンキング アプリをモダナイズ

スマートシティ チューリッヒ: 都市のデジタル トランスフォーメーションを推進している Anthos の舞台裏

ハイブリッドおよびマルチクラウドの将来に向けた市の基盤づくり

イノベーションに向けて都市をオープンに

職員にセルフサービスと API 管理を提供する

チューリッヒのモダナイゼーション - 一度に 1 つのサービス

AbemaTV：Google Cloud の活用による徹底した負荷対策によって世界的スポーツ イベントにおいて安定した視聴体験を提供

高トラフィックに対応するためにシステム構成の見直しを実施、Google Cloud の性能をフル活用へ

当日に起こりうる問題を洗い出すために、PSO チームと連携して徹底した事前対策を実施

負荷試験・障害試験を最小限の手間で実施できるようにプラットフォームの改善を進めていく

Policy Controller ダッシュボード: Anthos と GKE のすべての環境で利用可能に

Policy Controller ダッシュボード

今すぐ使用を開始する

Anthos ハイブリッド環境のリファレンス アーキテクチャを発表

PSP のポリシーからポリシー バンドルへの移行

Policy Controller 以外の PSP 移行手段

Policy Controller を使用した PSP の移行

PSP の検証機能の移行

PSP のミューテーション

ミューテーションの移行

ミューテーションの構成

変更のテスト

ダッシュボードでの Pod Security Policy 違反の確認

クラスタでの Pod Security Policy バンドル違反のモニタリング

まとめ

今すぐ使用を開始する

コンテナ化されたマネージド マイクロサービスでモダナイゼーションを加速させる Ulta Beauty

未来のデジタル店舗を開設する

魅力的なパートナーシップ

Anthos でエンジニアリング リソースを最大限に活用する

今後の展望

新しい PCI DSS ポリシー バンドルで Kubernetes クラスタを強化し、ワークロードのコンプライアンスを大規模にモニタリングする

PCI DSS v3.2.1 ポリシー バンドル

PCI DSS v3.2.1 ポリシー バンドルを使用する

Policy ダッシュボードで PCI DSS ポリシー バンドルの違反を確認する

クラスタで PCI DSS ポリシー バンドル違反をモニタリングする

まとめ

使ってみる

新しい GitOps オブザーバビリティ ダッシュボードを使用して、Kubernetes 構成を大規模に管理する

主要コンポーネント

一般的な操作

まとめ

任天堂：新しい汎用ゲームサーバーを Google Kubernetes Engine、Cloud Spanner などを駆使して構築

Google Cloud なら Kubernetes や Istio をフルマネージドで使える

2021 年のローンチ後、すでに複数のタイトルで導入が進む

Kubernetes クラスタにポリシー バンドルを適用してポリシー準拠の状況を大規模にモニタリング

ポリシー バンドルの概要

使ってみる

Anthos Service Mesh によるマルチクラスタ Ingress の一元化

問題提起

アーキテクチャの図

このソリューションの導入方法

まとめ

Multicloud Mindset: マルチクラウドの世界におけるオープンソースとセキュリティについて考える

エピソード 5: オープンソースとマルチクラウドの交わるところ

エピソード 6: マルチクラウドにおけるセキュリティ上の新たな課題

お知らせ: Twitter スペースで Multicloud Mindset シリーズをご紹介

エピソード 1: 役員室内のマルチクラウド

エピソード 2: マルチクラウドに関する 5 つのすべきこととすべきでないこと

エピソード 3: Yugabyte のマルチクラウド への移行

エピソード 4: クラウドがマルチクラウドへ進化するにつれ、仕事も進化する

Twitter: AutoML を活用してユーザーが有意義なスペースを見つけられるようサポート

オンプレミスのエッジ VM 管理を目的とした Anthos の拡張: 一般提供開始

VM 管理のために Anthos を拡張する理由

VM とコンテナを同時に実行、管理する

新しい VM 評価ツールと移行ツールを使ってすぐに開始する

Anthos オンプレミスとベアメタル版 Anthos をベースにする Google Distributed Cloud Virtual

ArgoCD を使用して GKE クラスタのフリートを構築する

ArgoCD フリート アーキテクチャを構成する

基盤となるインフラストラクチャのセットアップ

ArgoCD クラスタを構成する

アプリケーション クラスタをフリートに接続する

新しいチーム アプリケーションと新しいクラスタを追加する

フリート全体でアプリケーションを段階的にロールアウトする

まとめ

Google Kubernetes Engine: 7 年の実績と 7 つの素晴らしいメリット

Anthos Service Mesh を使用して Google 社員のためにアプリを保護する

なぜでしょうか？

アーキテクチャ

Banco BV が GKE と Anthos でバンキングアプリをモダナイズ

スマートシティチューリッヒ: 都市のデジタルトランスフォーメーションを推進している Anthos の舞台裏

AbemaTV：Google Cloud の活用による徹底した負荷対策によって世界的スポーツイベントにおいて安定した視聴体験を提供

Anthos ハイブリッド環境のリファレンスアーキテクチャを発表

PSP のポリシーからポリシーバンドルへの移行

コンテナ化されたマネージドマイクロサービスでモダナイゼーションを加速させる Ulta Beauty

Anthos でエンジニアリングリソースを最大限に活用する

新しい PCI DSS ポリシーバンドルで Kubernetes クラスタを強化し、ワークロードのコンプライアンスを大規模にモニタリングする

PCI DSS v3.2.1 ポリシーバンドル

PCI DSS v3.2.1 ポリシーバンドルを使用する

Policy ダッシュボードで PCI DSS ポリシーバンドルの違反を確認する

クラスタで PCI DSS ポリシーバンドル違反をモニタリングする

新しい GitOps オブザーバビリティダッシュボードを使用して、Kubernetes 構成を大規模に管理する

Kubernetes クラスタにポリシーバンドルを適用してポリシー準拠の状況を大規模にモニタリング

ポリシーバンドルの概要

エピソード 3: Yugabyte のマルチクラウドへの移行

ArgoCD フリートアーキテクチャを構成する

アプリケーションクラスタをフリートに接続する

新しいチームアプリケーションと新しいクラスタを追加する

必須のアクセスポリシーの同期

スケールアウトコンピューティングクラスを使用した、GKE Autopilot への高スループットワークロードのデプロイ

スケールアウトコンピューティングクラスを使用した Arm ワークロードのデプロイ

スケールアウトコンピューティングクラスへの x86 ワークロードのデプロイ

スケールアウトコンピューティングクラスを使用した Spot Pod のデプロイ

スケールアウトコンピューティングクラスを GKE Autopilot でぜひお試しください。

従来のマルチクラスタソリューションで解決できなかった課題とは？