Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Cookpad summer internship 2019 - infra intro
Search
itkq
August 23, 2019
Technology
1
9.8k
Cookpad summer internship 2019 - infra intro
https://internship.cookpad.com/2019/summer/
の 5 日目の講義に使った資料です。
itkq
August 23, 2019
Tweet
Share
More Decks by itkq
See All by itkq
アクセス制御にまつわる改善 / Improving access control
itkq
0
770
SRE Lounge #13 Service Level at Ubie
itkq
3
2.3k
Where Chaos Engineering comes from, and what's next
itkq
6
7.6k
Re:silience から始めるカオスエンジニアリング生活 / A Life of Chaos Engineering Starting with Resilience
itkq
12
3.8k
サービスのパフォーマンス数値と 依存関係を用いたサービス同士の 協調スケール構想 / Web System Architecture #1
itkq
0
770
Other Decks in Technology
See All in Technology
Oracle Cloud Infrastructureデータベース・クラウド:各バージョンのサポート期間
oracle4engineer
PRO
28
13k
Zennのパフォーマンスモニタリングでやっていること
ryosukeigarashi
0
150
BLADE: An Attempt to Automate Penetration Testing Using Autonomous AI Agents
bbrbbq
0
320
SREが投資するAIOps ~ペアーズにおけるLLM for Developerへの取り組み~
takumiogawa
1
430
心が動くエンジニアリング ── 私が夢中になる理由
16bitidol
0
100
Shopifyアプリ開発における Shopifyの機能活用
sonatard
4
250
FlutterアプリにおけるSLI/SLOを用いたユーザー体験の可視化と計測基盤構築
ostk0069
0
100
OS 標準のデザインシステムを超えて - より柔軟な Flutter テーマ管理 | FlutterKaigi 2024
ronnnnn
0
220
初心者向けAWS Securityの勉強会mini Security-JAWSを9ヶ月ぐらい実施してきての近況
cmusudakeisuke
0
130
OCI Security サービス 概要
oracle4engineer
PRO
0
6.5k
これまでの計測・開発・デプロイ方法全部見せます! / Findy ISUCON 2024-11-14
tohutohu
3
370
Lambda10周年!Lambdaは何をもたらしたか
smt7174
2
110
Featured
See All Featured
Keith and Marios Guide to Fast Websites
keithpitt
409
22k
Building an army of robots
kneath
302
43k
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
Fantastic passwords and where to find them - at NoRuKo
philnash
50
2.9k
Designing for Performance
lara
604
68k
Mobile First: as difficult as doing things right
swwweet
222
8.9k
The Pragmatic Product Professional
lauravandoore
31
6.3k
4 Signs Your Business is Dying
shpigford
180
21k
Documentation Writing (for coders)
carmenintech
65
4.4k
Reflections from 52 weeks, 52 projects
jeffersonlam
346
20k
[RailsConf 2023] Rails as a piece of cake
palkan
52
4.9k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Transcript
Summer Internship 2019 10 Day Tech: Infrastructure 技術部 SRE グループ
@itkq
Day 5
None
メンバー紹介 •講師: @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 Rails
Monolith” ‣ https://speakerdeck.com/a_matsuda/the-recipe-for- the-worlds-largest-rails-monolith
None
None
None
超巨大 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/ hako Pull-Request
SRE 開発者 ① ② ③ ④ レビュー LGTM ⑤ 新規開発フロー
w/ hako Pull-Request SRE の介入は Pull- Request のレビューだけ => リードタイムが少なく スケールする
Docker イメージ CPU とメモリ割当 ALB ECS Task NGINX APP ECS
Task NGINX APP タスク数
hako-console 開発者・SRE の ための管理画面 各種リソースへのリンク ECS 関連の情報
hako-console 開発者・SRE の ための管理画面 各種リソースへのリンク ECS 関連の情報
サービス間通信はむずい •マイクロサービスは銀の弾丸ではなく解決しなければならない課題 がある; 特にサービス間通信 (実質コミュニケーションコスト) •アプリケーション開発者の視点 ‣ サービス間通信を実装しなければならない。複数サービスへのクエリ やテストなど考えることが増える •SRE
の視点 ‣ 障害の特定が難しくなったり、カスケード障害の対応などコスト増
サービス間通信の問題?
サービス間通信の問題?
サービス間通信の問題? 連鎖する障害 (カスケード障害)
サービス間通信の問題? •各サービスが一斉にリトライするとさらに延焼 •どことどこが通信しているのかもはや分からない •どこが元凶・どこを直せばいいかすぐ分からない
サービス間通信をいい感じにしたい •適切なリトライ/タイムアウト/サーキットブレイク •サービスディスカバリ (通信相手をいい感じに知りたい) •オブザバビリティ (サービス間通信状況を追跡できる) ‣ キャパシティプランニング ‣ 障害の原因究明
サービス間通信をいい感じにするには IUUQTTQFBLFSEFDLDPNUBJLJPCTFSWBCJMJUZTFSWJDFNFTIBOENJDSPTFSWJDFT
サービス間通信をいい感じにするには IUUQTTQFBLFSEFDLDPNUBJLJPCTFSWBCJMJUZTFSWJDFNFTIBOENJDSPTFSWJDFT
サービスメッシュの良さ •中央管理できオブザバビリティ指向 •アプリケーション (言語) に依存しない ‣ 自作 Ruby 用ライブラリはある (expeditor)
が… •サービスメッシュやるぞ!!
サービスメッシュを選んだ
権限移譲の取り組み (2) •サービス間通信の設定を GitHub で中央管理 •hako と同様の PR レビュープロセス
サーキットブレイカー リトライ タイムアウト
pantry というアプリの 通信先を追加します
pantry エラーになると赤くなる
通信状況が把握できる
通信状況が把握できる
アプリ以外のリソース管理 •普通サービスにはアプリケーション以外の様々なリソースが 必要 ‣ データストア、キャッシュストア、CDN、… •これまで基本的に SRE が管理 ‣ 強い権限・責任が伴う、キャパシティプランニングが必要、…
‣ このままでは開発者主導で変更しづらい・スケールもしない
権限移譲の取り組み (3) •基本的に AWS のマネージドサービスを使う ‣ お金は上乗せされるが運用コストの軽減を狙う •リソースにはプロジェクト毎にタグをつけるよう徹底 ‣ プロジェクト毎の使用状況やコストを可視化
‣ 責任分割を徹底して GitHub フローに乗せるためには… ‣ Terraform ちゃんとやるぞ!!
•Infrastructure as Code のためのツール (OSS) •AWS, GCP, Azure, … 様々なプロバイダ
•エコシステムが育ちデファクトになりつつある ‣ これまでもクックパッドで使ってはいた ‣ ちなみにサーバの中身の構築には を使う
これまでの Terraform 運用 infra/infra2 SRE 大統一 Terraform terraform/ プッシュ・plan・apply すべてのリソースを
SRE が一元管理
これからの Terraform 運用 tech/terraform kirare/ ortensia/ stella-maris プッシュ (Project =
kirare) plan 独立 独立 プロジェクト毎に 分けて管理 それぞれ apply
None
•PR に対して CI で terraform plan が実行される ‣ 何が実際に変わるか事前に確認できる (dry-run)
‣ Project タグがないと落ちる ‣ 差分が良さそうだったら SRE が terraform apply で適用
これからの Terraform 運用 tech/terraform kirare/ ortensia/ stella-maris プッシュ (Project =
kirare) plan 独立 独立 プロジェクト毎に 分けて管理 それぞれ apply
リソースの利用状況? •リソースの管理は開発者主導でできるようになった •アプリを含むリソースは適切に利用されているか? ‣ オーバープロビジョニングしてないか ‣ 逆にサチったりしていないか •開発者がモニタリング/アラーティングできることが健全
権限移譲の取り組み (4) •アプリケーション開発者が設定することなく汎用的な モニタリング環境を提供する w/ hako-console ‣ マネージドな CloudWatch Metrics
‣ Grafana は便利
None
ステータスコード別 リクエスト数 レイテンシ パーセンタイル 各コンテナのメモリ タスク (インスタンス) 数 各コンテナの CPU
時間
RDS のフリーメモリ量 デプロイタイミング ElastiCache のヒット率
RDS のフリーメモリ量 デプロイタイミング ElastiCache のヒット率
権限移譲の取り組み (5) •Prometheus + Alertmanager で柔軟なモニタリング/ アラーティング設定を可能にする
•時系列 DB をもつモニタリングシステム (OSS) ‣ メトリクスに対する強力なクエリ言語 (PromQL) ‣ 動的なクラウド環境に向いているため流行りつつある •クックパッドでは
2017 年ぐらいから徐々に導入
コンテナ コンテナ サーバ サーバ 見つけて 取りに行く Alertmanager ルールに基づいて クエリ アラート
ダッシュボードを 見る クエリ モニタリング/アラーティング概観
hako-console Slack チャンネル を設定 Alertmanager レシーバを設定 Check Fire 通知 Validator
ルール設定 実装 通知先を取得 Fire システム Pull 開発 Validate Hako を中心としたアラーティングプラットフォームの図
hako-console Slack チャンネル を設定 Alertmanager レシーバを設定 Check Fire 通知 Validator
ルール設定 実装 通知先を取得 Fire システム Pull 開発 Check Hako を中心としたアラーティングプラットフォームの図 • 開発者は Slack チャンネルを設定するだけ でいい感じに • 必要なら自分でアラートも定義できる
hako-console Slack チャンネル を設定 Alertmanager レシーバを設定 Check Fire 通知 Validator
ルール設定 実装 通知先を取得 Fire システム Pull 開発 Check Hako を中心としたアラーティングプラットフォームの図 • SRE は汎用的なアラーティングを整備 して開発者のチャンネルに届けられる
Runbook #wangan
Runbook = アラート対応手順書
開発者自身も アラート設定できる (もちろんレビューする)
hako-console Slack チャンネル を設定 Alertmanager レシーバを設定 Check Fire 通知 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”