GCE Resources
プリエンプティブの場合
シャットダウンスクリプトで一応色々できるけど、1分くらいしか猶予はない
信用しすぎるのは微妙
プロジェクトまたぎの情報の共有はない。
Disk
Local SSD ゾーンをまたいで移動とかできない
LocalSSD使った場合のライブマイグレーションの対応はどうなってる？
→ 最近対応したはず
Network Load Balancer
リージョンに所属するリソース
Forwarding Rule→本体みたいなもん
向き先がターゲットプール。
これもリージョンに所属。
インスタンスはゾーンに所属する。
普通は複数ゾーンのインスタンスにする。
ターゲットプールにはインスタンスグループも設定できる。
Target Pool
同じリージョンに属してる必要がある。
バックアッププール
ゾーンのフェイルオーバーのためにバックアッププールを設定する。
ただし、正常な間はムダに立ち上がってるだけ
オートスケーラとバックアッププールは相性が悪い
立ち上がった直後はUnhealthyになる場合があるのでイマイチ。
ローリングアップデートとかで使う…？
HTTP Load Balancer
Webのトラフィックに限る。
Layer7。
URL Map→パスによって向き先を変える
後ろにはバックエンドサービス。
ターゲットプールみたいなもん
マルチリージョンサポート。
アクセス元によってバランサーに振り分け先のバックエンドサービスのゾーンを変えたりできる。
Instance Group
バッチ処理をしたいときにも便利に使えるよ。
インスタンステンプレート
手動と自動のスケーリングできる。
Unmanaged Instance Group
既存のインスタンスを任意で追加する。
Metadata
- KeyValue
- Instance Wide
- インスタンス固有のメタデータ
- Project Wide
- プロジェクト全体共通のメタデータ
GCP HTTPロードバランサーの運用例@マナボ
Network Load Balancer
L4ロードバランサー
- Session Afinity
- SSL Terminationがない
- 単一リージョンのみ
HTTP Load Balancing
L7ロードバランサ
1グローバルIPでできる。→すごい
近さを考慮した自動で振り分けをしてくれる
CPUの負荷がカツカツだと近くてもそっちに振り分けないとか賢く振り分けてくれる
- Firewall Rule
- ターゲットタグ
- インスタンス
- 普通にGCE
- ターゲットタグを設定してやる
- ヘルスチェック
- 閾値を設定してあげる
- 外部IPアドレス
- ロードバランサーの外部IP
- HTTPロードバランサーの場合はグローバルを設定
- ロードバランサー
- グローバル転送ルールの作成
- 4のグローバルIPを指定
- ここで証明書を入れる
- HTTP, HTTPSは別設定なので注意
- インスタンスグループ
- ゾーンにつき一つ
- 2のインスタンスを追加する
- 他のゾーンのグループも作る
- バックエンドサービス
- 複数のゾーン、複数のグループを設定するのが普通
- 分散モード
- デフォルトがしんどくなったときにどこに分散させるのかを設定するやつ
- 使用率とレート
- CPU使用率
- 1秒当たりのリクエスト数
- ヘルスチェックを設定
- バックエンドは複数追加する
Tips
- ファイアウォールをよりセキュアに
- LBを前に立ててるから、インスタンスのファイアウォールはIPを制限するようにする
- インスタンスのグローバルIPを除去する
- 内部IPだけあれば通信できるので、External IPを外していい感じになる
- メンテ
- メタデータ使ってやるのがオシャレなやりかた
- 即座にLBから切り離し
- iptablesでLBからのリクエストを遮断すると外れる
- 即座に外してくれるのでアクセスできないクライアントは出ない
- インスタンステンプレ
- スナップショット作っとくと便利
- インスタンスはスナップショットから作るといい感じ
プロダクションで使えるよ！
GCEの運用事例
SocketIO使ってる
当時MariaDB使ってた
RedisはDBのクエリ数減らすために間に入れてた
細かくシャーディングして使ってる。
落ちてなくなってても問題ない
ゲームって秒間3万クエリ捌けないとアカン
RedisのPub/Sub使ってた
負荷かかるとレイテンシが微妙になってきて自分でも梅雨オになった
Consul使って色々状態を見てやってる
サーバーが落ちるとボスが逃げる演出ｗ
Global Crown
WebRTCを利用したリアルタイム動画対話型レッスン
フロントはPHP、Nginx
HaProxyでハンドリング
ちょっと前まではMySQL
Percona Extra Cluster
Nearlineは安くて良いけど、スループットがイマイチで欲しいときに取り出せない
1週間以降は触らないからNearlineに移すとかやってる
capy
法人向け不正ログイン対策
すげーでかい
80インスタンスくらい
RAMノードが2台、1台はディスク
元はAWSだったけどGCPに移行した
Elasticsearchめっちゃ活用してる
色んなエラーとかから何から全部入れてる
Photonもやってる。
台数は言えないけど。
メタデータめっちゃ活用してる。
そろそろ
CentOSやめようぜ
epel, remiの金剛でコンフリクトでOSぶっ壊れてる
debian/ubuntuいいよ
まず
base系ライブラリを利用
consul
serfは将来的に廃し
terraform→神
マジで神
ただしバイナリはでかい
rerun
Bash Command Line Framework
envutils
マニアック
clutils
consul/serfの自動設定
ここでメタデータ超使ってる
clctl
オーケストレーションツール
influxdb / grafana
監視計のデータベースとダッシュボードに使ってる
データを入れる為に色々つながってる
gmonitorで監視
どこにも集中管理する仕組みがない。
だから何台増えても困らない
glauncher
マニアック
strecherのGCS版
名前はまだない
Backup Framework
Cloud Monitoring
設定ファイル作のめんどいから自動化した
CloudLogging
Syslog、コマンド発行履歴を取得
TerraformはDeployment Managerよりいい？
Deployment Managerツラい
CMで世界中に配信されるレベルのゲームの場合は…
キューイングで後でデータベースに入れる形
Write, Readのウェイト次第で色々変わる
GAE + GCEの運用事例
Office Hourよろしく！
内部資料より詳しい事例紹介！
サービス内容
rinkak
rinkak MMS
システム構成
GCE
CoffeeScriptとPython混ぜると死ぬ
Typescript使った方がいい
GCE(サーバー側)にデータは持ってない
GCEからCloud Datastoreにアクセスできるけど、構成が複雑になるのでやってない
GAE
2ドメイン
Python
Blog用にWordPressを立ててる。→モジュールを分けてる
Why GAE + GCE
上記構成はAppEngineだけでできる
- 独自ドメイン運用したい場合がある
- Google Apps for Workが必要
GCEでやるしかない
でも知見も溜まった
GCE深掘り
ネットワーク系の話
HTTP LoadBalancer使ってない。
WebSocket使う可能性があったから
ターゲットプールでBlue-Green Deploymentしてる
OSのアップデートやら、ミドルウェアをアップデートやらの時に使ってる
インスタンスグループのローリングアップデートくるくる詐欺なので信用しない方が良い
マルチAZにした理由
AZレベルの障害は1回のみ。
インスタンス周り
Startup scriptでDockerを立ち上げてる
インスタンステンプレートクソめんどくさい
更新できないクソ
Docker Image
Bitbucket使ってる
Jenkinsが自動ビルドして、GCRにPushしてる
Jenkinsはデプロイ作業をしない
バージョンをメタデータに登録してるだけ
Watcher
Metadataサーバを監視してる
MetaDataサーバー使ってないやつは×××
本当に大事。
Metadataサーバー
クソ便利
更新は苦手
裏側
GCS使ってる
Signed URLは発行する度にリモートコール起きるのでパフォーマンスは悪くなりがちだから注意
Cloud Monitoring
今のとこタダだから入れとこう
Cloud Logging
BigQueryに入れてる
今後とまとめ
大体ほとんど同じ構成になるはず。
パターン化されてる。
AWSのクラウドデザパタほとんど適用可能。
読んどくといいよ。
Terraform
Terraformってなに？
Hashicorp公開したプロダクト
マルチクラウド対応
インフラ構成管理ツール
Terraform GCPリソース35コ
だいぶ増えてきた