Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Confidential & Proprietary
Spanner から GKE、Spinnaker、そして SRE まで
コロプラが今挑戦していること
Confidential & Proprietary
Agenda
● マイグレーションについて
● 新しいアーキテクチャー
○ GKEについて
○ Spinnakerについて
○ Spannerについて
● SREの取り組み
Confidential & Proprietary
實方 和幸
業務推進部 インフラグループ 第1インフラチーム リーダー
マイグレーションについて
Confidential & Proprietary
コロプラのゲームインフラ構成
Confidential & Proprietary
従来までのマイグレーション方法
Confidential & Proprietary
従来までのマイグレーション方法
Confidential & Proprietary
従来までのマイグレーション方法
auto increment
を上げる
Confidential & Proprietary
マイグレーション時の問題
VPN通信のパケット数上限にあたる
(PPS問題)
Confidential & Proprietary
マイグレーション時の問題
x
Confidential & Proprietary
解決策
居合抜き
Confidential & Proprietary
居合抜き
1. 既存環境とGCP環境をVPN接続
2. GCP環境にAPP/PVP/KVS/DBを構築
3. DBをVPN経由でレプリケーション設定
4. 既存環境にPROXYを追加
5. ...
Confidential & Proprietary
居合抜き
1. 既存環境とGCP環境をVPN接続
2. GCP環境にAPP/PVP/KVS/DBを構築
3. DBをVPN経由でレプリケーション設定
4. 既存環境にPROXYを追加
5. ...
Confidential & Proprietary
従来までのマイグレーション
Confidential & Proprietary
居合抜き
Confidential & Proprietary
居合抜き
● メリット
○ 一瞬で切り替わる
● デメリット
○ 後戻りできない
Confidential & Proprietary
邵 正(しょう せい)
業務推進部 インフラグループ 第2インフラチーム リーダー
github.com/axot
新しいアーキテクチャー
Confidential & Proprietary
コロプラのゲームインフラ構成
Confidential & Proprietary
この構成の問題点
● オートスケールの実現が難しい
● 自動復旧しない
● 構成の管理が難しい
● DBが単一障害点
Confidential & Proprietary
コロプラのゲームインフラ新構成
Confidential & Proprietary
コロプラのゲームインフラ新構成
Confidential & Proprietary
コロプラのゲームインフラ新構成
Confidential & Proprietary
まとめ
● オートスケールの実現が難しい→GKE + Spinnaker
● 自動復旧しない→GKE
● 構成の管理が難しい→Spanner + GKE
● DBが単一障害点→Spanner
Confidential & Proprietary
奥村 開里
GKEについて
業務推進部 インフラグループ 第2インフラチーム
新しいアーキテクチャー
Confidential & Proprietary
今から話す部分 GKE
Confidential & Proprietary
GKEにする我々の主な理由
● 主に次の3つを導入したいため
○ 自動復旧
○ インフラ構成のコード化
○ オートスケール
● 全てKubernetesで解決できそうではある
○ 結局Kub...
Confidential & Proprietary
自動復旧
● 今までの問題
○ ロードバランサーからの
ヘルスチェックだけだと復旧しない
■ ロードバランサーから
切り離すだけ
■ プロセス再起動等の復旧は
試みない
■ 応答の無いプロセ...
Confidential & Proprietary
自動復旧
● 今までの問題
○ ロードバランサーの配下に無い
コンポーネントは自己監視の仕組みがな
い
■ 外部から監視する必要
■ 外部から復旧を試みるのは難しい
Confidential & Proprietary
解決策
Kubernetesに監視してもらう
Confidential & Proprietary
自動復旧
● Kubernetesの自己監視の仕組み
を使用
○ 異常を検知すると退避ではなく、
復旧
○ Kubernetes管理下にすればロード
バランサーに関係なく自己監視
○ フォー...
Confidential & Proprietary
インフラのコード化
● 今までの問題
○ VMを使い捨て運用できていない
■ 現在稼働しているインフラとコードの差分
がわからない
○ アプリケーションの設定とミドルウェアの設定が分離
■ ...
Confidential & Proprietary
解決策
Kubernetesのリソースとして全て管理
Confidential & Proprietary
インフラのコード化
● コンテナ化による恩恵
○ アプリケーションとミドルウェアのパッケージ化
■ 動く保証のあるミドルウェアとアプリケーションの組み
合わせをデプロイ
○ Immutabl...
Confidential & Proprietary
インフラのコード化
● Kubernetesによって
○ インフラ構成
○ ミドルウェア設定
■ 双方の差分の検知
が容易
Confidential & Proprietary
オートスケール
● なぜ必要なのか
○ ゲームではリクエスト数
が跳ねる
■ イベント
■ 時間帯
○ 人力スケールは難しい
○ インフラコストの
適正化をしたい
Confidential & Proprietary
オートスケール
● 我々が必要としていた
要件と直面した問題
○ ゲームだとイベント等により
大幅なスパイク
■ 手動でのスケーリングと
の両立が必要
Confidential & Proprietary
オートスケール
● 我々が必要としていた要件と直面した問題
○ 頻繁なデプロイを行う
■ デプロイ中にスケールすると差分がでてしまう
■ デプロイ中にスケーリングの発動を止めたり等が煩雑
に
Confidential & Proprietary
解決策
Kubernetesによるオートスケーリングとコ
ンテナによるデプロイ
Confidential & Proprietary
オートスケール
● リクエストが増加
● CPU使用率増加
Confidential & Proprietary
オートスケール
● コンテナ(Pod)を同じ
設定で起動して追加
Confidential & Proprietary
オートスケール
● 新しいコンテナ(Pod)を追
加できなくなる
● Node(インスタンス)を追
加
Confidential & Proprietary
オートスケール
● 新しく起動したNode(イ
ンスタンス)にPod(コン
テナ)を追加
Confidential & Proprietary
オートスケール
● この方式ならば現在稼働しているコンテナのイメージで起動す
るので最新であることが保証される
○ 頻繁なデプロイが可能
● 手動でのスケールもKubernetesならば容易...
Confidential & Proprietary
まとめ
● 自動復旧
○ Kubernetesの自己監視、自己復旧により実現
● インフラのコード化
○ コンテナ化によるインフラとアプリケーションの
パッケージング、Kubernetesに...
Confidential & Proprietary
問題
● 各種コンテナイメージのバージョン管理が
煩雑になりがち
● 手動でのスケールも現在の状態を可視化する必要
● デプロイツールがなく、コンテナイメージのIDなどの管理をして
いると破...
Confidential & Proprietary
解決策
Spinnakerによる可視化と
CI/CD、可視化
Confidential & Proprietary
邵 正(しょう せい)
Spinnakerについて
業務推進部 インフラグループ 第2インフラチーム リーダー
github.com/axot
新しいアーキテクチャー
Confidential & Proprietary
Spinnakerのメリット
● 柔軟な設定が可能なパイプライン
● 可視化とリソースマッピング
● バージョン管理
Confidential & Proprietary
Confidential & Proprietary
Confidential & Proprietary
Confidential & Proprietary
CI/CDのフロー
Confidential & Proprietary
粟田 大樹
Spannerについて
クリエイティブ本部 第1エンジニアリング部 第4グループ
新しいアーキテクチャー
Confidential & Proprietary
コロプラのゲームインフラ新構成
Confidential & Proprietary
コロプラの運用とSpanner
● メンテナンスを入れずに運用するのに適している!
● スケーリングが容易
○ Cloud Spanner の最も大きな恩恵!
○ ダウンタイムなし
○ 素早...
Confidential & Proprietary
コロプラの運用とSpanner
Confidential & Proprietary
アプリケーション側からの観点
● 開発段階で MySQL から Spanner への移行
● DB分割が不要に
○ 水平分割 や master / slave を意識したコードが不要にな
り...
Confidential & Proprietary
アプリケーション側からの観点
● PHP との連携
○ Spanner は PDO 非対応のため、独自 driver を開発
PDO
Laravel DB driver
社内独自 Mappe...
Confidential & Proprietary
アプリケーション側からの観点
● Spanner Client Library for PHP
○ Github で疑問点や不具合の報告がすぐできる
○ エンジニアからすぐにレスポンスがあり...
Confidential & Proprietary
アプリケーション側からの観点
● MySQL からの移行はさくっとはいかない
● 考え方を変える必要がある
○ Spanner を「すごい MySQL」と思わないこと
○ 特にPK, Ind...
Confidential & Proprietary
アプリケーション側からの観点
● マスタデータの更新
○ (開発時) INSERT / UPDATE / DELETE のSQL文がない
○ 更新系は API でやる必要がある
○ 運営がデ...
Confidential & Proprietary
Spanner Tips
● CREATE DATABASE, CREATE TABLE は同時にする
○ extra_statements[] に DDL を入れる
○ 個別にやるよりはる...
Confidential & Proprietary
関根 秀治
クリエイティブ本部 第1エンジニアリング部 第5グループ
SREの取り組み
Confidential & Proprietary
なぜ SRE なのか
Confidential & Proprietary
コロプラの運用体制
Confidential & Proprietary
運用における課題
サーバーアプリケーション - 機能実装が優先
● 運用の効率化が後手になり手作業が多い
● パフォーマンスへの意識が薄くなりがち
インフラ - プロジェクトから遠い
● イ...
Confidential & Proprietary
運用における課題
● イベントや新機能リリース時のサービスの信頼性
● 運用の効率化
個人のスキル / 努力に依存してなりたっている
仕組み化しよう
Confidential & Proprietary
SRE
サイトリライアビリティエンジニアリング
というワードを掲げ模索が始まる
Confidential & Proprietary
SREとは
Confidential & Proprietary
SREとは
“Google社が提唱、実践しているシステム管理とサービス運用の方法論
である” - Wikipedia
“SREとは、ソフトウェアエンジニアに運用チームの設計を依頼したときに
...
Confidential & Proprietary
SREをやろうとすればするほど
分からなくなってきた
Confidential & Proprietary
何をすればよいのか
SLO
SLI
エラーバジェット
自動化
トイル
ポストモーテム
モニタリング
リリースエンジニアリング
オンコール
Confidential & Proprietary
誰がどういう立ち位置で
インフラが? サーバーアプリケーションが? 新しいチームが?
● インフラだとサービスから遠い
● サーバーアプリケーションだと権限がない
● 新しいチーム…時間がか...
Confidential & Proprietary
ゲームに適用できるのか
SREの守備範囲はどこか
● 運用の範囲
○ ゲームでは運用と開発が混然一体となった運営
● 信頼性を保障する範囲
○ クライアント / アセット / 仕様 / 設定...
Confidential & Proprietary
SLO Workshop
Confidential & Proprietary
SLO Workshop
Google CREによるワークショップ
● 非英語圏では初の開催
● 本家本元のSREについて知ることができる
● SLI / SLO / エラーバジェット がテ...
Confidential & Proprietary
SLI (Service Level Indicator)
ユーザーが満足に利用できているかを計測する指標
重要なUserJourneyに対して設定する
● Good: エラー率 / レスポ...
Confidential & Proprietary
エラーバジェット
許容可能なエラー率
エラーバジェットが枯渇した場合は何らかの信頼性回復のアクショ
ンが求められる
exp. 可用性SLO 99.9% → 0.1%は許容
Confidential & Proprietary
Confidential & Proprietary
コロプラでのSRE
Confidential & Proprietary
何をすればよいのか
● SLI/SLOがSREにおけるコア
● ここの策定と実装が優先事項
Confidential & Proprietary
どういう体制か
Confidential & Proprietary
ゲームに適用できるのか
SREの範囲
● 運用の範囲
○ システム的な運用の範囲 / コンテンツ運用は行わない
● 信頼性を保障する範囲
○ サーバーではなくユーザー体験にフォーカス
エラー...
Confidential & Proprietary
具体的な活動
● SLI/SLOの策定とモニタリング仕組み実装
○ Stackdriver Logging / BigQuery 他
● 信頼性向上
○ パフォーマンス維持/改善
■ 設計/...
Confidential & Proprietary
新しい仲間を募集中
コロプラでは一緒に働く
サーバーサイドエンジニア
インフラエンジニア
を募集しています
皆様のご応募お待ちしております
Confidential & Proprietary
Thank you
Upcoming SlideShare
Loading in …5
×

Spanner から GKE、Spinnaker、そして SRE まで、コロプラが今挑戦していること[Google Cloud INSIDE Games & Apps]

2018 年 9 月 19 日(水)
第 5 回 Google Cloud INSIDE Games & Apps@Next '18

株式会社コロプラ

Spanner から GKE、Spinnaker、そして SRE まで、コロプラが今挑戦していること[Google Cloud INSIDE Games & Apps]

  1. 1. Confidential & Proprietary Spanner から GKE、Spinnaker、そして SRE まで コロプラが今挑戦していること
  2. 2. Confidential & Proprietary Agenda ● マイグレーションについて ● 新しいアーキテクチャー ○ GKEについて ○ Spinnakerについて ○ Spannerについて ● SREの取り組み
  3. 3. Confidential & Proprietary 實方 和幸 業務推進部 インフラグループ 第1インフラチーム リーダー マイグレーションについて
  4. 4. Confidential & Proprietary コロプラのゲームインフラ構成
  5. 5. Confidential & Proprietary 従来までのマイグレーション方法
  6. 6. Confidential & Proprietary 従来までのマイグレーション方法
  7. 7. Confidential & Proprietary 従来までのマイグレーション方法 auto increment を上げる
  8. 8. Confidential & Proprietary マイグレーション時の問題 VPN通信のパケット数上限にあたる (PPS問題)
  9. 9. Confidential & Proprietary マイグレーション時の問題 x
  10. 10. Confidential & Proprietary 解決策 居合抜き
  11. 11. Confidential & Proprietary 居合抜き 1. 既存環境とGCP環境をVPN接続 2. GCP環境にAPP/PVP/KVS/DBを構築 3. DBをVPN経由でレプリケーション設定 4. 既存環境にPROXYを追加 5. GCP環境DBMASTERのAuto incrementを上げる 6. 既存環境のPROXYにリダイレクト設定を入れ、リロード
  12. 12. Confidential & Proprietary 居合抜き 1. 既存環境とGCP環境をVPN接続 2. GCP環境にAPP/PVP/KVS/DBを構築 3. DBをVPN経由でレプリケーション設定 4. 既存環境にPROXYを追加 5. GCP環境DBMASTERのAuto incrementを上げる 6. 既存環境のPROXYにリダイレクト設定を入れ、リロード
  13. 13. Confidential & Proprietary 従来までのマイグレーション
  14. 14. Confidential & Proprietary 居合抜き
  15. 15. Confidential & Proprietary 居合抜き ● メリット ○ 一瞬で切り替わる ● デメリット ○ 後戻りできない
  16. 16. Confidential & Proprietary 邵 正(しょう せい) 業務推進部 インフラグループ 第2インフラチーム リーダー github.com/axot 新しいアーキテクチャー
  17. 17. Confidential & Proprietary コロプラのゲームインフラ構成
  18. 18. Confidential & Proprietary この構成の問題点 ● オートスケールの実現が難しい ● 自動復旧しない ● 構成の管理が難しい ● DBが単一障害点
  19. 19. Confidential & Proprietary コロプラのゲームインフラ新構成
  20. 20. Confidential & Proprietary コロプラのゲームインフラ新構成
  21. 21. Confidential & Proprietary コロプラのゲームインフラ新構成
  22. 22. Confidential & Proprietary まとめ ● オートスケールの実現が難しい→GKE + Spinnaker ● 自動復旧しない→GKE ● 構成の管理が難しい→Spanner + GKE ● DBが単一障害点→Spanner
  23. 23. Confidential & Proprietary 奥村 開里 GKEについて 業務推進部 インフラグループ 第2インフラチーム 新しいアーキテクチャー
  24. 24. Confidential & Proprietary 今から話す部分 GKE
  25. 25. Confidential & Proprietary GKEにする我々の主な理由 ● 主に次の3つを導入したいため ○ 自動復旧 ○ インフラ構成のコード化 ○ オートスケール ● 全てKubernetesで解決できそうではある ○ 結局Kubernetesクラスタ自体の管理は大変 → GKEでマネージドなKubernetes
  26. 26. Confidential & Proprietary 自動復旧 ● 今までの問題 ○ ロードバランサーからの ヘルスチェックだけだと復旧しない ■ ロードバランサーから 切り離すだけ ■ プロセス再起動等の復旧は 試みない ■ 応答の無いプロセスが存在 してリソースが無駄に なる可能性
  27. 27. Confidential & Proprietary 自動復旧 ● 今までの問題 ○ ロードバランサーの配下に無い コンポーネントは自己監視の仕組みがな い ■ 外部から監視する必要 ■ 外部から復旧を試みるのは難しい
  28. 28. Confidential & Proprietary 解決策 Kubernetesに監視してもらう
  29. 29. Confidential & Proprietary 自動復旧 ● Kubernetesの自己監視の仕組み を使用 ○ 異常を検知すると退避ではなく、 復旧 ○ Kubernetes管理下にすればロード バランサーに関係なく自己監視 ○ フォールバックの仕組みと組み合わせれ ばエラー出すことなく自動復旧
  30. 30. Confidential & Proprietary インフラのコード化 ● 今までの問題 ○ VMを使い捨て運用できていない ■ 現在稼働しているインフラとコードの差分 がわからない ○ アプリケーションの設定とミドルウェアの設定が分離 ■ 開発は用意されたインフラを信じてデプロイ ■ どんなミドルウェア設定で動くのか アプリケーションには書いてない
  31. 31. Confidential & Proprietary 解決策 Kubernetesのリソースとして全て管理
  32. 32. Confidential & Proprietary インフラのコード化 ● コンテナ化による恩恵 ○ アプリケーションとミドルウェアのパッケージ化 ■ 動く保証のあるミドルウェアとアプリケーションの組み 合わせをデプロイ ○ Immutableなインフラ ■ コード化されたものと稼働しているものが一致している 保証
  33. 33. Confidential & Proprietary インフラのコード化 ● Kubernetesによって ○ インフラ構成 ○ ミドルウェア設定 ■ 双方の差分の検知 が容易
  34. 34. Confidential & Proprietary オートスケール ● なぜ必要なのか ○ ゲームではリクエスト数 が跳ねる ■ イベント ■ 時間帯 ○ 人力スケールは難しい ○ インフラコストの 適正化をしたい
  35. 35. Confidential & Proprietary オートスケール ● 我々が必要としていた 要件と直面した問題 ○ ゲームだとイベント等により 大幅なスパイク ■ 手動でのスケーリングと の両立が必要
  36. 36. Confidential & Proprietary オートスケール ● 我々が必要としていた要件と直面した問題 ○ 頻繁なデプロイを行う ■ デプロイ中にスケールすると差分がでてしまう ■ デプロイ中にスケーリングの発動を止めたり等が煩雑 に
  37. 37. Confidential & Proprietary 解決策 Kubernetesによるオートスケーリングとコ ンテナによるデプロイ
  38. 38. Confidential & Proprietary オートスケール ● リクエストが増加 ● CPU使用率増加
  39. 39. Confidential & Proprietary オートスケール ● コンテナ(Pod)を同じ 設定で起動して追加
  40. 40. Confidential & Proprietary オートスケール ● 新しいコンテナ(Pod)を追 加できなくなる ● Node(インスタンス)を追 加
  41. 41. Confidential & Proprietary オートスケール ● 新しく起動したNode(イ ンスタンス)にPod(コン テナ)を追加
  42. 42. Confidential & Proprietary オートスケール ● この方式ならば現在稼働しているコンテナのイメージで起動す るので最新であることが保証される ○ 頻繁なデプロイが可能 ● 手動でのスケールもKubernetesならば容易 ○ 手動及び自動でのスケールの両立
  43. 43. Confidential & Proprietary まとめ ● 自動復旧 ○ Kubernetesの自己監視、自己復旧により実現 ● インフラのコード化 ○ コンテナ化によるインフラとアプリケーションの パッケージング、Kubernetesによる設定管理 により実現 ● オートスケール ○ コンテナ化、デプロイ方式の変更により実現
  44. 44. Confidential & Proprietary 問題 ● 各種コンテナイメージのバージョン管理が 煩雑になりがち ● 手動でのスケールも現在の状態を可視化する必要 ● デプロイツールがなく、コンテナイメージのIDなどの管理をして いると破綻する
  45. 45. Confidential & Proprietary 解決策 Spinnakerによる可視化と CI/CD、可視化
  46. 46. Confidential & Proprietary 邵 正(しょう せい) Spinnakerについて 業務推進部 インフラグループ 第2インフラチーム リーダー github.com/axot 新しいアーキテクチャー
  47. 47. Confidential & Proprietary Spinnakerのメリット ● 柔軟な設定が可能なパイプライン ● 可視化とリソースマッピング ● バージョン管理
  48. 48. Confidential & Proprietary
  49. 49. Confidential & Proprietary
  50. 50. Confidential & Proprietary
  51. 51. Confidential & Proprietary CI/CDのフロー
  52. 52. Confidential & Proprietary 粟田 大樹 Spannerについて クリエイティブ本部 第1エンジニアリング部 第4グループ 新しいアーキテクチャー
  53. 53. Confidential & Proprietary コロプラのゲームインフラ新構成
  54. 54. Confidential & Proprietary コロプラの運用とSpanner ● メンテナンスを入れずに運用するのに適している! ● スケーリングが容易 ○ Cloud Spanner の最も大きな恩恵! ○ ダウンタイムなし ○ 素早い反映(〜1分) ● スキーマのオンライン更新が容易
  55. 55. Confidential & Proprietary コロプラの運用とSpanner
  56. 56. Confidential & Proprietary アプリケーション側からの観点 ● 開発段階で MySQL から Spanner への移行 ● DB分割が不要に ○ 水平分割 や master / slave を意識したコードが不要にな りすっきり ● インタリーブとの相性 ○ 特定データを同じ分散領域に保存する機能 ○ ゲームのデータはユーザーに紐付いたものが多い ○ インタリーブの特性が活かせる
  57. 57. Confidential & Proprietary アプリケーション側からの観点 ● PHP との連携 ○ Spanner は PDO 非対応のため、独自 driver を開発 PDO Laravel DB driver 社内独自 Mapper 独自 driver Laravel DB driver 社内独自 Mapper google/cloud-spanner
  58. 58. Confidential & Proprietary アプリケーション側からの観点 ● Spanner Client Library for PHP ○ Github で疑問点や不具合の報告がすぐできる ○ エンジニアからすぐにレスポンスがあり 非常にやりやすかった!
  59. 59. Confidential & Proprietary アプリケーション側からの観点 ● MySQL からの移行はさくっとはいかない ● 考え方を変える必要がある ○ Spanner を「すごい MySQL」と思わないこと ○ 特にPK, Index, Transactionの特性 ● ノウハウをサーバーエンジニアにレクチャー
  60. 60. Confidential & Proprietary アプリケーション側からの観点 ● マスタデータの更新 ○ (開発時) INSERT / UPDATE / DELETE のSQL文がない ○ 更新系は API でやる必要がある ○ 運営がデータ更新したい場合に困る ○ 環境間の差分を Spanner に反映するツールを開発 ■ 開発環境でテスト ■ OKであれば本番環境と差分をとって反映
  61. 61. Confidential & Proprietary Spanner Tips ● CREATE DATABASE, CREATE TABLE は同時にする ○ extra_statements[] に DDL を入れる ○ 個別にやるよりはるかに速い! ● ログ・集計系は BigQuery 等にまかせる ○ Cloud Spanner は集計苦手 ● (PHP) SessionPoolCache, AuthCache 指定する ○ パフォーマンス出すためには必須 ● etc...
  62. 62. Confidential & Proprietary 関根 秀治 クリエイティブ本部 第1エンジニアリング部 第5グループ SREの取り組み
  63. 63. Confidential & Proprietary なぜ SRE なのか
  64. 64. Confidential & Proprietary コロプラの運用体制
  65. 65. Confidential & Proprietary 運用における課題 サーバーアプリケーション - 機能実装が優先 ● 運用の効率化が後手になり手作業が多い ● パフォーマンスへの意識が薄くなりがち インフラ - プロジェクトから遠い ● イベントスケジュールやユーザー様の熱量が分からない ● サービス固有の機能や実装について把握しきれない
  66. 66. Confidential & Proprietary 運用における課題 ● イベントや新機能リリース時のサービスの信頼性 ● 運用の効率化 個人のスキル / 努力に依存してなりたっている 仕組み化しよう
  67. 67. Confidential & Proprietary SRE サイトリライアビリティエンジニアリング というワードを掲げ模索が始まる
  68. 68. Confidential & Proprietary SREとは
  69. 69. Confidential & Proprietary SREとは “Google社が提唱、実践しているシステム管理とサービス運用の方法論 である” - Wikipedia “SREとは、ソフトウェアエンジニアに運用チームの設計を依頼したときに できあがるものです。” “私たちは業界用語のDevOpsとは一線を画しています。私たちも確かに インフラストラクチャをコードとして捉えてはいますが、私たちが焦点を当 てているのは信頼性です。” - SRE サイトリライアビリティエンジニアリング
  70. 70. Confidential & Proprietary SREをやろうとすればするほど 分からなくなってきた
  71. 71. Confidential & Proprietary 何をすればよいのか SLO SLI エラーバジェット 自動化 トイル ポストモーテム モニタリング リリースエンジニアリング オンコール
  72. 72. Confidential & Proprietary 誰がどういう立ち位置で インフラが? サーバーアプリケーションが? 新しいチームが? ● インフラだとサービスから遠い ● サーバーアプリケーションだと権限がない ● 新しいチーム…時間がかかる
  73. 73. Confidential & Proprietary ゲームに適用できるのか SREの守備範囲はどこか ● 運用の範囲 ○ ゲームでは運用と開発が混然一体となった運営 ● 信頼性を保障する範囲 ○ クライアント / アセット / 仕様 / 設定は?
  74. 74. Confidential & Proprietary SLO Workshop
  75. 75. Confidential & Proprietary SLO Workshop Google CREによるワークショップ ● 非英語圏では初の開催 ● 本家本元のSREについて知ることができる ● SLI / SLO / エラーバジェット がテーマ ○ “SRE needs SLO”
  76. 76. Confidential & Proprietary SLI (Service Level Indicator) ユーザーが満足に利用できているかを計測する指標 重要なUserJourneyに対して設定する ● Good: エラー率 / レスポンスタイム ● Bad: CPU使用率等のシステムメトリクス SLO (Service Level Objective) SLIに対する数値目標 ● SLOを満たしている = happy ● SLOを割り込む = unhappy
  77. 77. Confidential & Proprietary エラーバジェット 許容可能なエラー率 エラーバジェットが枯渇した場合は何らかの信頼性回復のアクショ ンが求められる exp. 可用性SLO 99.9% → 0.1%は許容
  78. 78. Confidential & Proprietary
  79. 79. Confidential & Proprietary コロプラでのSRE
  80. 80. Confidential & Proprietary 何をすればよいのか ● SLI/SLOがSREにおけるコア ● ここの策定と実装が優先事項
  81. 81. Confidential & Proprietary どういう体制か
  82. 82. Confidential & Proprietary ゲームに適用できるのか SREの範囲 ● 運用の範囲 ○ システム的な運用の範囲 / コンテンツ運用は行わない ● 信頼性を保障する範囲 ○ サーバーではなくユーザー体験にフォーカス エラー率 / レイテンシー フレームレート / クライアントの遷移時間 etc... ○ SREだけでは対応不能な事象は他人を頼る
  83. 83. Confidential & Proprietary 具体的な活動 ● SLI/SLOの策定とモニタリング仕組み実装 ○ Stackdriver Logging / BigQuery 他 ● 信頼性向上 ○ パフォーマンス維持/改善 ■ 設計/実装レビュー ■ 継続的監視と改善 ○ SLIに影響がある(と思われる)エラー解消 ● 開発の効率化
  84. 84. Confidential & Proprietary 新しい仲間を募集中 コロプラでは一緒に働く サーバーサイドエンジニア インフラエンジニア を募集しています 皆様のご応募お待ちしております
  85. 85. Confidential & Proprietary Thank you

×