Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
スタートアップが挑むクラウドネイティブなマルチリージョン戦略
Search
izumiiii
November 28, 2023
Technology
240
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
スタートアップが挑むクラウドネイティブなマルチリージョン戦略
Google Cloud Next Tokyo 2023 - Innovators Hive Lightning Talk
izumiiii
November 28, 2023
More Decks by izumiiii
See All by izumiiii
CircleCIの実行時間を大幅に短縮した話
izumiiii
0
130
GKE Autopilotのコストを9000円/日から2000円/日へ!
izumiiii
0
860
Multi-cluster deployment using ArgoCD x Connect Gateway
izumiiii
0
320
Other Decks in Technology
See All in Technology
分析AIエージェントを育てる、動く環境を育てる
codatum
1
890
二歩目のフロントエンド・ウェブアクセシビリティ
camiha
2
370
go-sqletch
moznion
0
130
SDDの運用にめげずに向き合った話
sansantech
PRO
1
140
初対面のメンバーがチームを組み、Claude Codeでゼロからサービスをリリース
mkdev10
1
120
今こそ知りたいAmplifyGen2
mkdev10
2
160
「Docker Desktop不要の時代」は 来たのか?
ueponx
0
490
OR学会2026年秋期大会_機械学習と数理最適化の融合による、配合レシピ最適化システム開発事例
brainpadpr
0
130
不可逆な意思決定を避けながら10億超の顧客データを AI Ready にするデータ基盤設計
baseballyama
1
300
Essential architectural thinking (revised edition)
ufried
0
110
AI駆動開発の時代になったのでトヨタ生産方式から見直す
terurou
7
5.8k
「事実」を「計測」して、「解釈」する 〜AWS Lambdaのメモリ最適解の見つけ方〜
maimyyym
0
130
Featured
See All Featured
技術選定の審美眼(2025年版) / Understanding the Spiral of Technologies 2025 edition
twada
PRO
120
120k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
12
1.3k
Groundhog Day: Seeking Process in Gaming for Health
codingconduct
0
400
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
21
1.7k
The Anti-SEO Checklist Checklist. Pubcon Cyber Week
ryanjones
0
260
Getting science done with accelerated Python computing platforms
jacobtomlinson
2
530
Money Talks: Using Revenue to Get Sh*t Done
nikkihalliwell
0
520
Technical Leadership for Architectural Decision Making
baasie
3
600
Believing is Seeing
oripsolob
1
240
Building Flexible Design Systems
yeseniaperezcruz
330
41k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.9k
Color Theory Basics | Prateek | Gurzu
gurzu
1
480
Transcript
スタートアップが挑むクラウドネイティブなマルチリージョン戦略 Google Cloud Next Tokyo 2023 - Innovators Hive Lightning
Talk
自己紹介 名前 Koizumi Fumiya Twitter izumiiii @izumiiii9 Blog https://izumiiii.com Zenn
https://zenn.dev/izumiiii 会社 株式会社Resilire 普段していること インフラ業務メインで、最近はよくKubernetesを触っています。
提供プロダクト Resilreの提供価値と機能 3 サプライチェーンリスク管理SaaS Resilire サプライチェーン全体(社内拠点や委託先、原料 調達先)をツリー上で構造的に管理。災害時、被 災影響の可能性がある拠点をマップ上で可視化・ リスト化。リストの拠点に自動でアンケート配信か ら回答結果のレポート生成を可能にするプロダク
トを提供しています。 3
インフラの重要性 • Resilireは災害時のリスク管理を行うプロダクトのため、平常時の予防よりも特に災害時にも 動作し続ける必要があります。 • 例えば、震災があったとしたら、納入先とサプライヤーの間で物流・生産に影響がないかをResilireのプ ロダクトを通して確認しあうような形で使われます。 • サプライヤーは海外にいることも多いため、グローバルに利用継続性を高める必要があり、 災害時にグローバルでも動作し続けられる基盤作りにチャレンジする必要があります。
急成長に伴う課題の発生 • 費用、人員、時間の制限 ◦ 少数の開発組織でありながら、決められた期間内にサービスをリリースする必要性があった。 • 既存システムの管理コストの増大 ◦ デプロイシステムのコード量が増加し、保守コストが増えた。 •
新アプリケーションとサービスの増加 ◦ リアーキテクチャのサービスの洗い出しによって、サービス数が増えた。また、グローバルに耐えうるシステム 構成が必要であった。
我々が挑むマルチリージョン戦略のシステム
GCPサービス
Google Kubernetes Engine Autopilot • アプリケーションに専念 ◦ Googleがインフラストラクチャを管理するため、エンジニアはアプリケーションに専念。 • 運用の複雑さの軽減
◦ Autopilot は、ノード、スケーリング、スケジューリングのオペレーションを継続的にモニ タリングする必要がないため、プラットフォームの管理オーバーヘッドを削減。 Resilire では、少数の開発組織のため運用の簡素化された Autopilot が適している。
マルチクラスタ Ingress • グローバル負荷分散 ◦ ユーザートラフィックを最も効率的で効果的なクラスタやリージョンに自動的にルーティン グ。 • リージョナルな冗長性と可用性の向上 ◦
複数のリージョンにクラスタを展開することで、リージョナルな冗長性と高可用性を実現。 Resilireではグローバル展開を想定しているため、有効な手段。
Managed Anthos Service Mesh • クラスター間をサービスメッシュを設けることで、クラスター間通信、可用性の向上、トラフィッ ク分散、サーキットブレイカーを行うことができる。 • Resilireでは、クラスタ間の負荷分散、BCP対策として活用。
東京クラスタ 大阪クラスタ ??クラスタ 海外
Spot Pod for Autopilot vCPU, Memory当たり1/3程度の料金で使える。 注意点: 標準の Pod の実行でコンピューティングリソースが必要になると、GKE
に よって強制削除される場合がある。
apiVersion: apps/v1 kind: Deployment metadata: name: argocd-repo-server spec: template: spec:
containers: - name: argocd-repo-server nodeSelector: cloud.google.com/gke-spot: 'true' terminationGracePeriodSeconds: 25 設定例
リソースリクエスト Autopilotでのノードのインスタンスタイプ/ノード数は実際にクラスタにデプロイ されているPodに設定されたRequest量をもとに決定されている。 明示的にリソース量をマニフェストで指定していない場合、1コンテナあたり 0.5 vCPU, 2GiB Memoryが割り当てられる。
注意点 Autopilotでは1Podあたり最低 CPU: 250m メモリ: 0.5 GiB を割り当てないといけない。 それより小さい値を指定していても、値が変わらないようになっている。
apiVersion: apps/v1 kind: Deployment metadata: name: argocd-repo-server spec: template: spec:
containers: - name: argocd-repo-server resources: requests: cpu: 250m memory: 512Mi 設定例
まとめ • GKE Autopilotを使うことによって、複雑な管理コストを減らして、アプリケーションに専念。 • マルチクラスタIngress, Anthos Service Meshを使うことで、BCP対策を意識したり、グローバルユー ザーを意識したレイテンシの改善を行うことができる。
• Spot Pod,リソースリクエストを使うことで、簡単な編集でコストを削減してGKEを運用することができる。
ご清聴ありがとうございました。