Cookpad summer internship 2019 - infra intro

E4619fc2a039391a1677beeac58dd487?s=47 itkq
August 23, 2019

Cookpad summer internship 2019 - infra intro

https://internship.cookpad.com/2019/summer/ の 5 日目の講義に使った資料です。

E4619fc2a039391a1677beeac58dd487?s=128

itkq

August 23, 2019
Tweet

Transcript

  1. 2.
  2. 3.
  3. 6.

    講師 •ID: itkq •職歴: 新卒2年目 ‣ 長野高専 → 東工大 →

    クックパッド (イマココ) •仕事: 障害に強いシステムをつくりたい ‣ カオスエンジニアリングとか •趣味: 最近は Re:ステージ! にハマっている
  4. 8.

    今日の流れ •講義 ‣ クックパッドのインフラの変遷 (イマココ) ‣ API サーバ (Day 3)

    のデプロイの裏側 •講義 + ハンズオン ‣ トピック: 認証認可・DynamoDB •実践 (残り時間) ‣ インフラを意識した API サーバの拡張・開発環境の整備
  5. 12.

    SRE •Site Reliability Engineering ‣ Google が言い出した ‣ “ソフトウェアエンジニア”による信頼性工学 •

    “インフラエンジニア” じゃない ‣ とりあえず名前だけ覚えておいてください
  6. 16.

    時は 2015 年 •“The Recipe for the World’s Largest Rails

    Monolith” ‣ https://speakerdeck.com/a_matsuda/the-recipe-for- the-worlds-largest-rails-monolith
  7. 17.
  8. 18.
  9. 19.
  10. 21.

    当時の図 (雰囲気) tech/cookpad_all 課金 ユーザ情報 検索 レシピ つくれぽ 調整 調整

    調整 調整 調整 調整 調整 … プッシュ &&
 デプロイしたい!! インフラ 運用
  11. 34.

    そして SRE へ •“インフラ” → “SRE” ‣ 主業務がインフラ調達・運用から自動化・効率化のためのソ フトウェア開発運用へ徐々にシフト •技術部

    開発基盤グループとも協力が多くなった ‣ “開発環境” → ”プラットフォーム” ‣ 2019 年現在では組織再編で SRE に吸収された
  12. 36.
  13. 37.

    クックパッドのコンテナ動作環境 •AWS ECS (2015 ~) ‣ Docker コンテナのオーケストレーションを提供するマネージドサービ ス。これ自体で実際のユースケースをカバーするのは当時難しかった •hako

    ‣ 宣言的に記述した定義をもとにデプロイするツール。ECS へのデプロ イに使われている。OSS になっている。現在ではクックパッドの中心 的なエコシステム・プラットフォームに。
  14. 39.

    SRE 開発者 ① ② ③ ④ レビュー LGTM ⑤ 新規開発フロー

    w/ hako Pull-Request SRE の介入は Pull- Request のレビューだけ => リードタイムが少なく スケールする
  15. 61.

    •Infrastructure as Code のためのツール (OSS) •AWS, GCP, Azure, … 様々なプロバイダ

    •エコシステムが育ちデファクトになりつつある ‣ これまでもクックパッドで使ってはいた ‣ ちなみにサーバの中身の構築には を使う
  16. 63.

    これからの Terraform 運用 tech/terraform kirare/ ortensia/ stella-maris プッシュ
 (Project =

    kirare)
 plan 独立 独立 プロジェクト毎に
 分けて管理 それぞれ 
 apply
  17. 64.
  18. 65.

    •PR に対して CI で terraform plan が実行される ‣ 何が実際に変わるか事前に確認できる (dry-run)

    ‣ Project タグがないと落ちる ‣ 差分が良さそうだったら SRE が terraform apply で適用
  19. 66.

    これからの Terraform 運用 tech/terraform kirare/ ortensia/ stella-maris プッシュ
 (Project =

    kirare)
 plan 独立 独立 プロジェクト毎に
 分けて管理 それぞれ 
 apply
  20. 69.
  21. 75.

    コンテナ コンテナ サーバ サーバ 見つけて
 取りに行く Alertmanager ルールに基づいて クエリ アラート

    ダッシュボードを
 見る クエリ モニタリング/アラーティング概観
  22. 76.

    hako-console Slack チャンネル を設定 Alertmanager レシーバを設定 Check Fire 通知 Validator

    ルール設定 実装 通知先を取得 Fire システム Pull 開発 Validate Hako を中心としたアラーティングプラットフォームの図
  23. 77.

    hako-console Slack チャンネル を設定 Alertmanager レシーバを設定 Check Fire 通知 Validator

    ルール設定 実装 通知先を取得 Fire システム Pull 開発 Check Hako を中心としたアラーティングプラットフォームの図 • 開発者は Slack チャンネルを設定するだけ でいい感じに • 必要なら自分でアラートも定義できる
  24. 78.

    hako-console Slack チャンネル を設定 Alertmanager レシーバを設定 Check Fire 通知 Validator

    ルール設定 実装 通知先を取得 Fire システム Pull 開発 Check Hako を中心としたアラーティングプラットフォームの図 • SRE は汎用的なアラーティングを整備
 して開発者のチャンネルに届けられる
  25. 82.

    hako-console Slack チャンネル を設定 Alertmanager レシーバを設定 Check Fire 通知 Validator

    ルール設定 実装 通知先を取得 Fire システム Pull 実装/設定
  26. 83.

    What’s next? •デプロイ、サービス間通信、リソース管理、モニタリング、アラー ティングは移譲が進んできた (2019 年) •この先どうやってアプリケーション開発者と SRE で “運用”

    
 するべきなのか ‣ 本番環境でエラーが出ていたら誰がどう対処するべき? ‣ ユーザにどれぐらい影響があったか (ビジネスインパクトは) ? ‣ 機能開発の手を止めて信頼性の改善に集中すべき?
  27. 85.

    運用シナリオ① システム システム ①エンバグ ①エンバグ ②帰宅 ②帰宅 ③アラート ③アラート ④オンコール対応

    •Dev: 機能優先で信頼性をおろそかにしてしまう ‣ アプリケーションコードの品質の低下 •Ops: アプリケーション起因のアラート対応 ‣ ドメイン知識がないままバグを修正することになり
 消耗
  28. 87.

    運用シナリオ② システム システム 慎重な開発 慎重な開発 デプロイ デプロイ •Dev: 障害を恐れた慎重な開発 ‣

    機能リリース速度・回数の低下 •Ops ‣ サービスが成長しないのでやれることがない…
  29. 89.

    どうすれば…? •信頼性リスクを 0 にするのは不可能なことを思い出す ‣ “Everything fails, all the time.”

    •Dev も Ops も障害を “受け入れる” ‣ どれぐらい “受け入れられるか” を定義する • 例: サービスが 10 分落ちたらいくら損失するか?
  30. 90.

    SLI と SLO •サービスレベル指標 (SLI) ‣ 例: Uptime •サービスレベル目標 (SLO)

    ‣ 例: 月の Uptime: 99.95% (= 月に 22 分落ちてもいい) ‣ Biz, Dev, SRE すべてで共通する目標