Cookpad summer internship 2019 - infra intro

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

Transcript

1. Summer Internship 2019
 10 Day Tech: Infrastructure 技術部 SRE グループ @itkq
2. Day 5
4. メンバー紹介 •講師: @itkq (SRE グループ) •TA: (全員 SRE グループ) ‣ @hfm ‣ @mozamimy ‣ @rrreeeyyy
5. 自己紹介
6. 講師 •ID: itkq •職歴: 新卒2年目 ‣ 長野高専 → 東工大 → クックパッド (ｲﾏｺｺ) •仕事: 障害に強いシステムをつくりたい ‣ カオスエンジニアリングとか •趣味: 最近は Re:ステージ! にハマっている
7. TA 各位の自己紹介!
8. 今日の流れ •講義 ‣ クックパッドのインフラの変遷 (ｲﾏｺｺ) ‣ API サーバ (Day 3) のデプロイの裏側 •講義 + ハンズオン ‣ トピック: 認証認可・DynamoDB •実践 (残り時間) ‣ インフラを意識した API サーバの拡張・開発環境の整備
9. 最初の講義テーマ •“クックパッドのインフラ” ‣ 普段趣味でプロダクトを作るだけでは知れないような
 現場のインフラの話をします ‣ 今年のインターンがなぜこういう構成だったのかが
 きっと分かる
10. 突然の組織構成 ʜ SRE グループ
11. 突然の組織構成 ʜ SRE グループ •各開発チーム ‣ プロダクトの開発に集中して価値を提供 •SRE ‣ 横断的に各開発チームのインフラ・信頼性の担保
12. SRE •Site Reliability Engineering ‣ Google が言い出した ‣ “ソフトウェアエンジニア”による信頼性工学 • “インフラエンジニア” じゃない ‣ とりあえず名前だけ覚えておいてください
13. クックパッドを支えるインフラ •様々なサービスの安定稼働 ‣ クックパッド (レシピサービス)、クックパッドマート、… •ピーク時は結構トラフィックがある ‣ レシピサービスが一番使われるのは夕方
14. レシピサービスの一週間 17~18時 スマホ API Web 月曜日
15. クックパッドのインフラの特徴 •AWS (クラウド) のフル活用 •巨大モノリシックアプリケーションに特化したインフ ラからマイクロサービス指向のインフラへ変遷 ‣ 権限移譲とセルフサービス化 •コスト最適化, etc.
16. 時は 2015 年 •“The Recipe for the World’s Largest Rails Monolith” ‣ https://speakerdeck.com/a_matsuda/the-recipe-for- the-worlds-largest-rails-monolith
20. 超巨大 Rails を支えるインフラ •mamiya ‣ 高速デプロイツール。15分かかっていたデプロイが20秒で終わるように •RRRSpec ‣ 並列分散テストツール。1時間かかっていたテストが15分で終わるように •SpotScaler ‣ 安い EC2 スポットインスタンスを活用したオートスケーラー
21. 当時の図 (雰囲気) tech/cookpad_all 課金 ユーザ情報 検索 レシピ つくれぽ 調整 調整 調整 調整 調整 調整 調整 … プッシュ &&
 デプロイしたい!! インフラ 運用
22. 当時の様子① •検索ロジックを改善するためにモデルを30行変更してみた •モデルは他の機能と密結合していて全然関係なく思えるテストが数百 単位で落ちる •がんばって修正していく •その間に別のチームが他の変更をデプロイしていて、いざブランチを マージしようとするととんでもなくコンフリクトした •いつまでも変更をリリースできない… ＼(^o^)／ｵﾜﾀ
23. 当時の様子② •A/B テストの結果が良さそうだったので新しい機能を本番リリース したい •しかし結構影響範囲が大きいため別のチームと調整する必要がある •GitHub 上で非同期的な議論するのは時間がかかるので各チームと ひたすらミーティングをする •調整が終わってコードを書き始められるのは1ヶ月後だった…
 ＼(^o^)／ｵﾜﾀ
24. •価値を提供したいだけなのにどうして… 消耗
25. 問題点 IUUQTUFDIMJGFDPPLQBEDPNFOUSZPEBJCBTUSBUFHZ
26. 問題点 (続) IUUQTUFDIMJGFDPPLQBEDPNFOUSZPSDIBC⒎
27. モノリシックの限界 •最初はうまくいっていたが組織とサービスが成長するに つれて素早い価値提供が難しくなった ‣ 密結合によるコミュニケーション・メンテナンスコストの増加 •我々は本質的にはサービスを提供したい ‣ レシピサービス以外のサービスも立ち上げたいフェーズ •2014 年からマイクロサービスアーキテクチャへ移行開始
28. 3行で分かるマイクロサービスアーキテクチャ •Kubernetes 上のコンテナで動いていて •最新の技術が使われていて •規模が小さいサービスの集まり
29. 3行で分かるマイクロサービスアーキテクチャ •Kubernetes 上のコンテナで動いていて •最新の技術が使われていて •規模が小さいサービスの集まり 全部間違ってる!!!
30. 3行で分かる本当のマイクロサービスアーキテクチャ •(Why) 組織全体のパフォーマンス最大化するために •(How) 開発からリリースまでのサイクルを回して コミュニケーションコストを下げることで •(What) 巨大化した組織とシステムを再編するための アーキテクチャ
31. マイクロサービス詳細 •時間の関係で割愛します
32. 理想のマイクロサービス Airbnb Netflix
33. マイクロサービスアーキテクチャとインフラ •インフラグループはレシピサービスのインフラを支えていたが、 以降新旧様々なサービスのインフラも支えていかなければならなく なった •個々のサービスのインフラを用意したりデプロイしたり運用の サポートをするのではコミュニケーションコストが高くなり スケールもしない ‣ マネージドサービスを活用しつつ権限移譲とセルフサービス化に
 取り組む
34. そして SRE へ •“インフラ” → “SRE” ‣ 主業務がインフラ調達・運用から自動化・効率化のためのソ フトウェア開発運用へ徐々にシフト •技術部 開発基盤グループとも協力が多くなった ‣ “開発環境” → ”プラットフォーム” ‣ 2019 年現在では組織再編で SRE に吸収された
35. SRE 開発者 ① これまでの新規開発フロー ② サーバ準備・配置 ③ デプロイ
 スクリプト用意 ④
36. 権限移譲の取り組み (1) •これまでアプリケーションのデプロイとはインフラに大きく
 関係していた ‣ インスタンス準備、ミドルウェア・ライブラリ更新、… •コンテナ技術 (Docker) の台頭 ‣ アプリケーション開発者が実行環境まで制御可能になり docker run さえできる場を用意すれば良くなった ‣ コンテナ化やるぞ!!
37. クックパッドのコンテナ動作環境 •AWS ECS (2015 ~) ‣ Docker コンテナのオーケストレーションを提供するマネージドサービ ス。これ自体で実際のユースケースをカバーするのは当時難しかった •hako ‣ 宣言的に記述した定義をもとにデプロイするツール。ECS へのデプロ イに使われている。OSS になっている。現在ではクックパッドの中心 的なエコシステム・プラットフォームに。
38. SRE 開発者 ① ② ③ ④ レビュー LGTM ⑤ 新規開発フロー w/ hako Pull-Request
39. SRE 開発者 ① ② ③ ④ レビュー LGTM ⑤ 新規開発フロー w/ hako Pull-Request SRE の介入は Pull- Request のレビューだけ => リードタイムが少なく スケールする
40. Docker イメージ CPU とメモリ割当 ALB ECS Task NGINX APP ECS Task NGINX APP タスク数
41. hako-console 開発者・SRE の ための管理画面 各種リソースへのリンク ECS 関連の情報
42. hako-console 開発者・SRE の ための管理画面 各種リソースへのリンク ECS 関連の情報
43. サービス間通信はむずい •マイクロサービスは銀の弾丸ではなく解決しなければならない課題 がある; 特にサービス間通信 (実質コミュニケーションコスト) •アプリケーション開発者の視点 ‣ サービス間通信を実装しなければならない。複数サービスへのクエリ やテストなど考えることが増える •SRE の視点 ‣ 障害の特定が難しくなったり、カスケード障害の対応などコスト増
44. サービス間通信の問題?
45. サービス間通信の問題?
46. サービス間通信の問題? 連鎖する障害 (カスケード障害)
47. サービス間通信の問題? •各サービスが一斉にリトライするとさらに延焼 •どことどこが通信しているのかもはや分からない •どこが元凶・どこを直せばいいかすぐ分からない
48. サービス間通信をいい感じにしたい •適切なリトライ/タイムアウト/サーキットブレイク •サービスディスカバリ (通信相手をいい感じに知りたい) •オブザバビリティ (サービス間通信状況を追跡できる) ‣ キャパシティプランニング ‣ 障害の原因究明
49. サービス間通信をいい感じにするには IUUQTTQFBLFSEFDLDPNUBJLJPCTFSWBCJMJUZTFSWJDFNFTIBOENJDSPTFSWJDFT
50. サービス間通信をいい感じにするには IUUQTTQFBLFSEFDLDPNUBJLJPCTFSWBCJMJUZTFSWJDFNFTIBOENJDSPTFSWJDFT
51. サービスメッシュの良さ •中央管理できオブザバビリティ指向 •アプリケーション (言語) に依存しない ‣ 自作 Ruby 用ライブラリはある (expeditor) が… •サービスメッシュやるぞ!!
52. サービスメッシュを選んだ
53. 権限移譲の取り組み (2) •サービス間通信の設定を GitHub で中央管理 •hako と同様の PR レビュープロセス
54. サーキットブレイカー リトライ タイムアウト
55. pantry というアプリの 通信先を追加します
56. pantry エラーになると赤くなる
57. 通信状況が把握できる
58. 通信状況が把握できる
59. アプリ以外のリソース管理 •普通サービスにはアプリケーション以外の様々なリソースが 必要 ‣ データストア、キャッシュストア、CDN、… •これまで基本的に SRE が管理 ‣ 強い権限・責任が伴う、キャパシティプランニングが必要、… ‣ このままでは開発者主導で変更しづらい・スケールもしない
60. 権限移譲の取り組み (3) •基本的に AWS のマネージドサービスを使う ‣ お金は上乗せされるが運用コストの軽減を狙う •リソースにはプロジェクト毎にタグをつけるよう徹底 ‣ プロジェクト毎の使用状況やコストを可視化 ‣ 責任分割を徹底して GitHub フローに乗せるためには… ‣ Terraform ちゃんとやるぞ!!
61. •Infrastructure as Code のためのツール (OSS) •AWS, GCP, Azure, … 様々なプロバイダ •エコシステムが育ちデファクトになりつつある ‣ これまでもクックパッドで使ってはいた ‣ ちなみにサーバの中身の構築には を使う
62. これまでの Terraform 運用 infra/infra2 SRE 大統一 Terraform terraform/ プッシュ・plan・apply すべてのリソースを
 SRE が一元管理
63. これからの Terraform 運用 tech/terraform kirare/ ortensia/ stella-maris プッシュ
 (Project = kirare)
 plan 独立 独立 プロジェクト毎に
 分けて管理 それぞれ 
 apply
65. •PR に対して CI で terraform plan が実行される ‣ 何が実際に変わるか事前に確認できる (dry-run) ‣ Project タグがないと落ちる ‣ 差分が良さそうだったら SRE が terraform apply で適用
66. これからの Terraform 運用 tech/terraform kirare/ ortensia/ stella-maris プッシュ
 (Project = kirare)
 plan 独立 独立 プロジェクト毎に
 分けて管理 それぞれ 
 apply
67. リソースの利用状況? •リソースの管理は開発者主導でできるようになった •アプリを含むリソースは適切に利用されているか? ‣ オーバープロビジョニングしてないか ‣ 逆にサチったりしていないか •開発者がモニタリング/アラーティングできることが健全
68. 権限移譲の取り組み (4) •アプリケーション開発者が設定することなく汎用的な モニタリング環境を提供する w/ hako-console ‣ マネージドな CloudWatch Metrics ‣ Grafana は便利
70. ステータスコード別
 リクエスト数 レイテンシ
 パーセンタイル 各コンテナのメモリ タスク (インスタンス) 数 各コンテナの CPU 時間
71. RDS のフリーメモリ量 デプロイタイミング ElastiCache のヒット率
72. RDS のフリーメモリ量 デプロイタイミング ElastiCache のヒット率
73. 権限移譲の取り組み (5) •Prometheus + Alertmanager で柔軟なモニタリング/ アラーティング設定を可能にする
74. •時系列 DB をもつモニタリングシステム (OSS) ‣ メトリクスに対する強力なクエリ言語 (PromQL) ‣ 動的なクラウド環境に向いているため流行りつつある •クックパッドでは 2017 年ぐらいから徐々に導入
75. コンテナ コンテナ サーバ サーバ 見つけて
 取りに行く Alertmanager ルールに基づいて クエリ アラート ダッシュボードを
 見る クエリ モニタリング/アラーティング概観
76. hako-console Slack チャンネル を設定 Alertmanager レシーバを設定 Check Fire 通知 Validator ルール設定 実装 通知先を取得 Fire システム Pull 開発 Validate Hako を中心としたアラーティングプラットフォームの図
77. hako-console Slack チャンネル を設定 Alertmanager レシーバを設定 Check Fire 通知 Validator ルール設定 実装 通知先を取得 Fire システム Pull 開発 Check Hako を中心としたアラーティングプラットフォームの図 • 開発者は Slack チャンネルを設定するだけ でいい感じに • 必要なら自分でアラートも定義できる
78. hako-console Slack チャンネル を設定 Alertmanager レシーバを設定 Check Fire 通知 Validator ルール設定 実装 通知先を取得 Fire システム Pull 開発 Check Hako を中心としたアラーティングプラットフォームの図 • SRE は汎用的なアラーティングを整備
 して開発者のチャンネルに届けられる
79. Runbook #wangan
80. Runbook = アラート対応手順書
81. 開発者自身も
 アラート設定できる
 (もちろんレビューする)
82. hako-console Slack チャンネル を設定 Alertmanager レシーバを設定 Check Fire 通知 Validator ルール設定 実装 通知先を取得 Fire システム Pull 実装/設定
83. What’s next? •デプロイ、サービス間通信、リソース管理、モニタリング、アラー ティングは移譲が進んできた (2019 年) •この先どうやってアプリケーション開発者と SRE で “運用” 
 するべきなのか ‣ 本番環境でエラーが出ていたら誰がどう対処するべき? ‣ ユーザにどれぐらい影響があったか (ビジネスインパクトは) ? ‣ 機能開発の手を止めて信頼性の改善に集中すべき?
84. 運用シナリオ① システム システム ①エンバグ ①エンバグ ②帰宅 ②帰宅 ③アラート ③アラート ④オンコール対応
85. 運用シナリオ① システム システム ①エンバグ ①エンバグ ②帰宅 ②帰宅 ③アラート ③アラート ④オンコール対応 •Dev: 機能優先で信頼性をおろそかにしてしまう ‣ アプリケーションコードの品質の低下 •Ops: アプリケーション起因のアラート対応 ‣ ドメイン知識がないままバグを修正することになり
 消耗
86. 運用シナリオ② システム システム 慎重な開発 慎重な開発 デプロイ デプロイ
87. 運用シナリオ② システム システム 慎重な開発 慎重な開発 デプロイ デプロイ •Dev: 障害を恐れた慎重な開発 ‣ 機能リリース速度・回数の低下 •Ops ‣ サービスが成長しないのでやれることがない…
88. •価値を提供したいだけなのにどうして… 消耗 (again) Dev Ops
89. どうすれば…? •信頼性リスクを 0 にするのは不可能なことを思い出す ‣ “Everything fails, all the time.” •Dev も Ops も障害を “受け入れる” ‣ どれぐらい “受け入れられるか” を定義する • 例: サービスが 10 分落ちたらいくら損失するか?
90. SLI と SLO •サービスレベル指標 (SLI) ‣ 例: Uptime •サービスレベル目標 (SLO) ‣ 例: 月の Uptime: 99.95% (= 月に 22 分落ちてもいい) ‣ Biz, Dev, SRE すべてで共通する目標
91. SLO があると嬉しいこと •数値に基づいた具体的なコミュニケーションができる ‣ 「サービス落ちるとまずいんで落とさないようにしてく ださい!」みたいなのが無くなる ‣ SRE は必要十分なコストを払って信頼性の担保する動機 ができる
92. アプリケーション開発者の今後 •(当然) アプリケーションコードを書く •宣言的にインフラの設定を書く ‣ インフラは抽象化され誰でも触れるように •サービスレベルに従って開発・運用していく ‣ “DevOps”