Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
スタートアップが挑むクラウドネイティブなマルチリージョン戦略
Search
izumiiii
November 28, 2023
Technology
230
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
840
Multi-cluster deployment using ArgoCD x Connect Gateway
izumiiii
0
310
Other Decks in Technology
See All in Technology
ポストモーテム! DDoSからサイトは守れた。 でもビジネスは守れなかった。
bengo4com
1
3k
なぜ私たちのSREプラクティスはなかなか機能しないのか 〜システムより先に組織を見る〜 / Why our SRE practices aren't really working
vtryo
3
3.8k
AI Agent SaaS を支える自社仮想化基盤への挑戦と実運用 / ai-agent-saas-virtualization
flatt_security
2
3.9k
ゴールデンパスは敷いただけでは道にならない ─ 企画部門のエンジニアが技術標準を事業価値に変えるまで
mhrtech
1
150
CSに"SLO"は要らない、経営層に"99.9%"は伝わらない - SREを全社に"翻訳"する3原則
cscengineer
PRO
1
4.6k
知らん間に、回ってる
ming_ayami
0
600
DatabricksにおけるMCPソリューション
taka_aki
1
250
“それは自分の仕事じゃない"を越えて行け
yuukiyo
1
350
人を動かすのは時間ではなく、納得感 〜新任EMが入社3ヶ月、組織を2回変えた話〜
kakehashi
PRO
3
220
関数型の考えを TypeScript に持ち込んで、テストしやすい純粋関数を増やす / Pure at the Core, Effects at the Edge: Bringing Functional Thinking into TypeScript
kaminashi
1
120
インフラ寄りSREでも 開発に踏み出せる〜境界を越えてユーザー体験に向き合いたい〜
sansantech
PRO
2
3.9k
クラウド上のデータ復旧で見落としがちな制約: 医療系 SaaS の BCP 設計から得た教訓
kakehashi
PRO
0
3.5k
Featured
See All Featured
B2B Lead Gen: Tactics, Traps & Triumph
marketingsoph
0
170
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
35
2.5k
Git: the NoSQL Database
bkeepers
PRO
432
67k
End of SEO as We Know It (SMX Advanced Version)
ipullrank
3
4.3k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
31
3.2k
Reflections from 52 weeks, 52 projects
jeffersonlam
356
21k
Applied NLP in the Age of Generative AI
inesmontani
PRO
4
2.4k
The Art of Programming - Codeland 2020
erikaheidi
57
14k
Marketing Yourself as an Engineer | Alaka | Gurzu
gurzu
0
260
The Curious Case for Waylosing
cassininazir
1
430
From π to Pie charts
rasagy
0
230
Balancing Empowerment & Direction
lara
6
1.2k
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を運用することができる。
ご清聴ありがとうございました。