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