ロボット工学のスタートアップがクラウドを切り替え、GKE Autopilot で Kubernetes の運用コストを削減

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

Brain Corp は、工場、スーパーマーケット、学校、倉庫で 2 万台以上のロボットを運用し、フロアの清掃、在庫の取り出し、棚の補充といった時間のかかる作業を担っています。また、こうした自動のモバイル ロボットを動かす AI のソフトウェア プラットフォームである BrainOS® は、ロボット自体で実行されるだけではなく、クラウド上でも実行されています。具体的には、Google Cloud 上で実行されています。

しかし、最初から Google Cloud だったわけではありません。Brain Corp は、最近、Google Cloud と連携し、ロボットのプラットフォームを Amazon EKS から、Google Kubernetes Engine（GKE）Autopilot に移行しました。本番環境で数千のロボットを稼働するということは、運用上の課題が大量に発生するということです。さらに、Brain Corp では、Kubernetes（k8s）上でプラットフォームを構築する際に通常であれば付随する、日常業務とセキュリティ メンテナンスのオーバーヘッドを減らす方法を必要としていました。

Brain Corp は、膨大な業務量となるクラスタの高可用性の維持、Google Cloud のサイト信頼性エンジニアリング（SREs）に対する最新のセキュリティ アップデートのパッチの適用というすべての業務を、Autopilot を有効にするだけでオフロードしました。Brain Corp の運用チームは、現在、k8s クラスタを「稼働させ続ける」ことだけではなく、新しいプラットフォームへの追加のロボットの移行に集中できています。

Google Cloud への切り替え

Brain Corp は EKS からの移行を決めた際に、データとロボットを簡単に統合できる最高のテクノロジー、ツール、プラットフォームを有するクラウドを探そうと考えていました。Brain Corp のクラウド開発チームは、まず Google Cloud やその他のクラウド プロバイダで、ロボットをサポートするための概念実証アーキテクチャの実装から試すことにしました。他のクラウド プロバイダでは概念実証の準備から運用までに 1 か月かかったところ、Google Cloud では、わずか 1 週間で完了したことから、Google Cloud が最適な選択肢であることは明白でした。

また Brain Corp は、概念実証中に、簡単に使用できるという以上のメリットに気が付きました。概念実証から本番環境への移行に極めて効果的だったのが、Google が重視するデータ プロダクト間のシンプルなインテグレーションでした。Brain Corp は、GKE Autopilot を使用して Kubernetes の運用タスクを Google SRE にオフロードできたため、Google Cloud 上の新たなプラットフォームへのロボットの移行に集中できました。

GKE Autopilot への切り替え

Brain Corp でクラウド インフラストラクチャのリーダーを務める Alex Gartner 氏は、「デベロッパーが、深く考え込む必要なしに迅速に開発とデプロイができるようにする」、これこそが彼の率いるチームの役割だと述べています。EKS を使用していたときは、Brain Corp は k8s を管理するためだけの専任のインフラストラクチャ エンジニアを割かなければいけませんでした。Gartner 氏は、Standard GKE でも同じようにエンジニアを割り当てるつもりでいましたが、Autopilot を使い始めるや否や、その必要がないことに気が付き、すぐに方針転換をしました。GKE Autopilot のクラスタは安全ですぐに使えて、Google SRE でサポートされているため、Brain Corp は運用コストを削減しながら、より安全でより優れた環境をお客様に提供できるようになりました。

また、開発環境により多くのガードレールが設置されていたことも、Autopilot に切り替えたもう 1 つの理由でした。以前の Brain Corp の開発環境では、ささいな構成ミスでクラスタが停止する可能性がありました。「Autopilot であれば、高可用性と機能が低下した状態で k8s クラスタをプロビジョニングする方法について、資料を隅々まで読み込む必要はありません」と Gartner 氏は述べています。Autopilot がない状態で、Autopilot がデフォルトで提供しているだけの安定性を実現するためには、GKE の障害シナリオの評価に丸 1 か月費やす必要があると、Gartner 氏は指摘します。「Google SRE は、自分たちのサービスをよく理解しているため、Brain Corp では考え付かないような障害シナリオを想定することが可能です」と Gartner 氏は述べます。たとえば、Brain Corp のエンジニアは割り当て不足や容量不足のシナリオをシミュレーションする確実な方法を持っていませんでした。

GKE Autopilot は Brain Corp をどうサポートしたのか

Autopilot を導入して以来、Brain Corp のクラウド インフラストラクチャ チームは、クラスタやサービスが予期せずダウンしたとして、深夜にページを受信する回数が少なくなっています。クラスタは、Google Cloud によってスケーリング、保守されています。Autopilot は、無効にできない高水準なガードレールをクラスタに組み込むことで、「より優れた防爆壁をデフォルトで提供してくれます」と Gartner 氏は述べています。また Autopilot では、大量の k8s の指標やパフォーマンス指標をデフォルトでエクスポートするため、パフォーマンス指標の収集や Grafana ダッシュボードでの可視化が劇的に容易になっています。「今では、情報収集自体や、収集方法の検討に時間をかける必要がなくなりました」と Gartner 氏は述べています。

また、Autopilot は Brain Corp のソフトウェア エンジニアのデベロッパー エクスペリエンスも改善しています。デベロッパーは大量のコンピューティング ジョブをバックグラウンドで実行しており、従来のままであれば Pod レベルで費用やコンピューティング要件を簡単に調整することはできませんでした。Autopilot の Pod ごとの請求では、透明性が増し、デベロッパーはジョブの費用を正確に把握することが可能となります。また、コンピューティング要件を自分たちで Pod に合わせて簡単に適応させることも可能です。クラスタレベルではなくアプリレベルの請求であるため、5 チームが使用するクラスタでオーバープロビジョニングして、請求をどう分割するかを検討するよりも、チャージバックが簡単になります。「k8s の請求の最適化に時間を使いたくはありません」と Gartner 氏は述べています。費用の削減は、Autopilot への切り替えの大きなメリットでした。Gartner 氏は、「k8s のノードを実行するだけで 5～10% のオーバーヘッドを請求されていましたが、今ではそうした請求はありません。アプリが実際に使用する分のみを支払っています」と話します。

どのように Autopilot を改善できるか

GKE Autopilot は、昨年リリースされ、まだ GKE ですべての機能をご利用いただける状態ではありません。たとえば、一部の科学的ワークロードでは、特定の CPU 命令セットの使用が求められる、またはそちらを使用する方が優れたパフォーマンスを発揮します。「GPU のサポートはぜひ実現していただきたいところです」と Gartner 氏は話します。とはいえ、EKS と比べた場合の GKE Autopilot のメリットはそうした制約をはるかに上回り、現状でも、特殊なワークロード向けに GKE Standard のクラスタを立ち上げることができます。

GKE Autopilot によってデベロッパーやエンジニアに還元できた時間のおかげで、Brain Corp はロボットの新機能の考案に多くの時間を費やすことができています。Brain Corp の活躍に今後も目が離せません。

GKE と GKE Autopilot に関心がある方は、Google Cloud の KubeCon トークをオンデマンドでご覧ください。