Tweet
Tweet

Slide 1

Slide 1 text

Summer Internship 2019
 10 Day Tech: Infrastructure 技術部 SRE グループ @itkq

Slide 2

Slide 2 text

Day 5

Slide 3

Slide 3 text

No content

Slide 4

Slide 4 text

メンバー紹介 •講師: @itkq (SRE グループ) •TA: (全員 SRE グループ) ‣ @hfm ‣ @mozamimy ‣ @rrreeeyyy

Slide 5

Slide 5 text

自己紹介

Slide 6

Slide 6 text

講師 •ID: itkq •職歴: 新卒2年目 ‣ 長野高専 → 東工大 → クックパッド (ｲﾏｺｺ) •仕事: 障害に強いシステムをつくりたい ‣ カオスエンジニアリングとか •趣味: 最近は Re:ステージ! にハマっている

Slide 7

Slide 7 text

TA 各位の自己紹介!

Slide 8

Slide 8 text

今日の流れ •講義 ‣ クックパッドのインフラの変遷 (ｲﾏｺｺ) ‣ API サーバ (Day 3) のデプロイの裏側 •講義 + ハンズオン ‣ トピック: 認証認可・DynamoDB •実践 (残り時間) ‣ インフラを意識した API サーバの拡張・開発環境の整備

Slide 9

Slide 9 text

最初の講義テーマ •“クックパッドのインフラ” ‣ 普段趣味でプロダクトを作るだけでは知れないような
 現場のインフラの話をします ‣ 今年のインターンがなぜこういう構成だったのかが
 きっと分かる

Slide 10

Slide 10 text

突然の組織構成 ʜ SRE グループ

Slide 11

Slide 11 text

突然の組織構成 ʜ SRE グループ •各開発チーム ‣ プロダクトの開発に集中して価値を提供 •SRE ‣ 横断的に各開発チームのインフラ・信頼性の担保

Slide 12

Slide 12 text

SRE •Site Reliability Engineering ‣ Google が言い出した ‣ “ソフトウェアエンジニア”による信頼性工学 • “インフラエンジニア” じゃない ‣ とりあえず名前だけ覚えておいてください

Slide 13

Slide 13 text

クックパッドを支えるインフラ •様々なサービスの安定稼働 ‣ クックパッド (レシピサービス)、クックパッドマート、… •ピーク時は結構トラフィックがある ‣ レシピサービスが一番使われるのは夕方

Slide 14

Slide 14 text

レシピサービスの一週間 17~18時 スマホ API Web 月曜日

Slide 15

Slide 15 text

クックパッドのインフラの特徴 •AWS (クラウド) のフル活用 •巨大モノリシックアプリケーションに特化したインフ ラからマイクロサービス指向のインフラへ変遷 ‣ 権限移譲とセルフサービス化 •コスト最適化, etc.

Slide 16

Slide 16 text

時は 2015 年 •“The Recipe for the World’s Largest Rails Monolith” ‣ https://speakerdeck.com/a_matsuda/the-recipe-for- the-worlds-largest-rails-monolith

Slide 17

Slide 17 text

No content

Slide 18

Slide 18 text

No content

Slide 19

Slide 19 text

No content

Slide 20

Slide 20 text

超巨大 Rails を支えるインフラ •mamiya ‣ 高速デプロイツール。15分かかっていたデプロイが20秒で終わるように •RRRSpec ‣ 並列分散テストツール。1時間かかっていたテストが15分で終わるように •SpotScaler ‣ 安い EC2 スポットインスタンスを活用したオートスケーラー

Slide 21

Slide 21 text

当時の図 (雰囲気) tech/cookpad_all 課金 ユーザ情報 検索 レシピ つくれぽ 調整 調整 調整 調整 調整 調整 調整 … プッシュ &&
 デプロイしたい!! インフラ 運用

Slide 22

Slide 22 text

当時の様子① •検索ロジックを改善するためにモデルを30行変更してみた •モデルは他の機能と密結合していて全然関係なく思えるテストが数百 単位で落ちる •がんばって修正していく •その間に別のチームが他の変更をデプロイしていて、いざブランチを マージしようとするととんでもなくコンフリクトした •いつまでも変更をリリースできない… ＼(^o^)／ｵﾜﾀ

Slide 23

Slide 23 text

当時の様子② •A/B テストの結果が良さそうだったので新しい機能を本番リリース したい •しかし結構影響範囲が大きいため別のチームと調整する必要がある •GitHub 上で非同期的な議論するのは時間がかかるので各チームと ひたすらミーティングをする •調整が終わってコードを書き始められるのは1ヶ月後だった…
 ＼(^o^)／ｵﾜﾀ

Slide 24

Slide 24 text

•価値を提供したいだけなのにどうして… 消耗

Slide 25

Slide 25 text

問題点 IUUQTUFDIMJGFDPPLQBEDPNFOUSZPEBJCBTUSBUFHZ

Slide 26

Slide 26 text

問題点 (続) IUUQTUFDIMJGFDPPLQBEDPNFOUSZPSDIBC⒎

Slide 27

Slide 27 text

モノリシックの限界 •最初はうまくいっていたが組織とサービスが成長するに つれて素早い価値提供が難しくなった ‣ 密結合によるコミュニケーション・メンテナンスコストの増加 •我々は本質的にはサービスを提供したい ‣ レシピサービス以外のサービスも立ち上げたいフェーズ •2014 年からマイクロサービスアーキテクチャへ移行開始

Slide 28

Slide 28 text

3行で分かるマイクロサービスアーキテクチャ •Kubernetes 上のコンテナで動いていて •最新の技術が使われていて •規模が小さいサービスの集まり

Slide 29

Slide 29 text

3行で分かるマイクロサービスアーキテクチャ •Kubernetes 上のコンテナで動いていて •最新の技術が使われていて •規模が小さいサービスの集まり 全部間違ってる!!!

Slide 30

Slide 30 text

3行で分かる本当のマイクロサービスアーキテクチャ •(Why) 組織全体のパフォーマンス最大化するために •(How) 開発からリリースまでのサイクルを回して コミュニケーションコストを下げることで •(What) 巨大化した組織とシステムを再編するための アーキテクチャ

Slide 31

Slide 31 text

マイクロサービス詳細 •時間の関係で割愛します

Slide 32

Slide 32 text

理想のマイクロサービス Airbnb Netflix

Slide 33

Slide 33 text

マイクロサービスアーキテクチャとインフラ •インフラグループはレシピサービスのインフラを支えていたが、 以降新旧様々なサービスのインフラも支えていかなければならなく なった •個々のサービスのインフラを用意したりデプロイしたり運用の サポートをするのではコミュニケーションコストが高くなり スケールもしない ‣ マネージドサービスを活用しつつ権限移譲とセルフサービス化に
 取り組む

Slide 34

Slide 34 text

そして SRE へ •“インフラ” → “SRE” ‣ 主業務がインフラ調達・運用から自動化・効率化のためのソ フトウェア開発運用へ徐々にシフト •技術部 開発基盤グループとも協力が多くなった ‣ “開発環境” → ”プラットフォーム” ‣ 2019 年現在では組織再編で SRE に吸収された

Slide 35

Slide 35 text

SRE 開発者 ① これまでの新規開発フロー ② サーバ準備・配置 ③ デプロイ
 スクリプト用意 ④

Slide 36

Slide 36 text

権限移譲の取り組み (1) •これまでアプリケーションのデプロイとはインフラに大きく
 関係していた ‣ インスタンス準備、ミドルウェア・ライブラリ更新、… •コンテナ技術 (Docker) の台頭 ‣ アプリケーション開発者が実行環境まで制御可能になり docker run さえできる場を用意すれば良くなった ‣ コンテナ化やるぞ!!

Slide 37

Slide 37 text

クックパッドのコンテナ動作環境 •AWS ECS (2015 ~) ‣ Docker コンテナのオーケストレーションを提供するマネージドサービ ス。これ自体で実際のユースケースをカバーするのは当時難しかった •hako ‣ 宣言的に記述した定義をもとにデプロイするツール。ECS へのデプロ イに使われている。OSS になっている。現在ではクックパッドの中心 的なエコシステム・プラットフォームに。

Slide 38

Slide 38 text

SRE 開発者 ① ② ③ ④ レビュー LGTM ⑤ 新規開発フロー w/ hako Pull-Request

Slide 39

Slide 39 text

SRE 開発者 ① ② ③ ④ レビュー LGTM ⑤ 新規開発フロー w/ hako Pull-Request SRE の介入は Pull- Request のレビューだけ => リードタイムが少なく スケールする

Slide 40

Slide 40 text

Docker イメージ CPU とメモリ割当 ALB ECS Task NGINX APP ECS Task NGINX APP タスク数

Slide 41

Slide 41 text

hako-console 開発者・SRE の ための管理画面 各種リソースへのリンク ECS 関連の情報

Slide 42

Slide 42 text

hako-console 開発者・SRE の ための管理画面 各種リソースへのリンク ECS 関連の情報

Slide 43

Slide 43 text

サービス間通信はむずい •マイクロサービスは銀の弾丸ではなく解決しなければならない課題 がある; 特にサービス間通信 (実質コミュニケーションコスト) •アプリケーション開発者の視点 ‣ サービス間通信を実装しなければならない。複数サービスへのクエリ やテストなど考えることが増える •SRE の視点 ‣ 障害の特定が難しくなったり、カスケード障害の対応などコスト増

Slide 44

Slide 44 text

サービス間通信の問題?

Slide 45

Slide 45 text

サービス間通信の問題?

Slide 46

Slide 46 text

サービス間通信の問題? 連鎖する障害 (カスケード障害)

Slide 47

Slide 47 text

サービス間通信の問題? •各サービスが一斉にリトライするとさらに延焼 •どことどこが通信しているのかもはや分からない •どこが元凶・どこを直せばいいかすぐ分からない

Slide 48

Slide 48 text

サービス間通信をいい感じにしたい •適切なリトライ/タイムアウト/サーキットブレイク •サービスディスカバリ (通信相手をいい感じに知りたい) •オブザバビリティ (サービス間通信状況を追跡できる) ‣ キャパシティプランニング ‣ 障害の原因究明

Slide 49

Slide 49 text

サービス間通信をいい感じにするには IUUQTTQFBLFSEFDLDPNUBJLJPCTFSWBCJMJUZTFSWJDFNFTIBOENJDSPTFSWJDFT

Slide 50

Slide 50 text

サービス間通信をいい感じにするには IUUQTTQFBLFSEFDLDPNUBJLJPCTFSWBCJMJUZTFSWJDFNFTIBOENJDSPTFSWJDFT

Slide 51

Slide 51 text

サービスメッシュの良さ •中央管理できオブザバビリティ指向 •アプリケーション (言語) に依存しない ‣ 自作 Ruby 用ライブラリはある (expeditor) が… •サービスメッシュやるぞ!!

Slide 52

Slide 52 text

サービスメッシュを選んだ

Slide 53

Slide 53 text

権限移譲の取り組み (2) •サービス間通信の設定を GitHub で中央管理 •hako と同様の PR レビュープロセス

Slide 54

Slide 54 text

サーキットブレイカー リトライ タイムアウト

Slide 55

Slide 55 text

pantry というアプリの 通信先を追加します

Slide 56

Slide 56 text

pantry エラーになると赤くなる

Slide 57

Slide 57 text

通信状況が把握できる

Slide 58

Slide 58 text

通信状況が把握できる

Slide 59

Slide 59 text

アプリ以外のリソース管理 •普通サービスにはアプリケーション以外の様々なリソースが 必要 ‣ データストア、キャッシュストア、CDN、… •これまで基本的に SRE が管理 ‣ 強い権限・責任が伴う、キャパシティプランニングが必要、… ‣ このままでは開発者主導で変更しづらい・スケールもしない

Slide 60

Slide 60 text

権限移譲の取り組み (3) •基本的に AWS のマネージドサービスを使う ‣ お金は上乗せされるが運用コストの軽減を狙う •リソースにはプロジェクト毎にタグをつけるよう徹底 ‣ プロジェクト毎の使用状況やコストを可視化 ‣ 責任分割を徹底して GitHub フローに乗せるためには… ‣ Terraform ちゃんとやるぞ!!

Slide 61

Slide 61 text

•Infrastructure as Code のためのツール (OSS) •AWS, GCP, Azure, … 様々なプロバイダ •エコシステムが育ちデファクトになりつつある ‣ これまでもクックパッドで使ってはいた ‣ ちなみにサーバの中身の構築には を使う

Slide 62

Slide 62 text

これまでの Terraform 運用 infra/infra2 SRE 大統一 Terraform terraform/ プッシュ・plan・apply すべてのリソースを
 SRE が一元管理

Slide 63

Slide 63 text

これからの Terraform 運用 tech/terraform kirare/ ortensia/ stella-maris プッシュ
 (Project = kirare)
 plan 独立 独立 プロジェクト毎に
 分けて管理 それぞれ 
 apply

Slide 64

Slide 64 text

No content

Slide 65

Slide 65 text

•PR に対して CI で terraform plan が実行される ‣ 何が実際に変わるか事前に確認できる (dry-run) ‣ Project タグがないと落ちる ‣ 差分が良さそうだったら SRE が terraform apply で適用

Slide 66

Slide 66 text

これからの Terraform 運用 tech/terraform kirare/ ortensia/ stella-maris プッシュ
 (Project = kirare)
 plan 独立 独立 プロジェクト毎に
 分けて管理 それぞれ 
 apply

Slide 67

Slide 67 text

リソースの利用状況? •リソースの管理は開発者主導でできるようになった •アプリを含むリソースは適切に利用されているか? ‣ オーバープロビジョニングしてないか ‣ 逆にサチったりしていないか •開発者がモニタリング/アラーティングできることが健全

Slide 68

Slide 68 text

権限移譲の取り組み (4) •アプリケーション開発者が設定することなく汎用的な モニタリング環境を提供する w/ hako-console ‣ マネージドな CloudWatch Metrics ‣ Grafana は便利

Slide 69

Slide 69 text

No content

Slide 70

Slide 70 text

ステータスコード別
 リクエスト数 レイテンシ
 パーセンタイル 各コンテナのメモリ タスク (インスタンス) 数 各コンテナの CPU 時間

Slide 71

Slide 71 text

RDS のフリーメモリ量 デプロイタイミング ElastiCache のヒット率

Slide 72

Slide 72 text

RDS のフリーメモリ量 デプロイタイミング ElastiCache のヒット率

Slide 73

Slide 73 text

権限移譲の取り組み (5) •Prometheus + Alertmanager で柔軟なモニタリング/ アラーティング設定を可能にする

Slide 74

Slide 74 text

•時系列 DB をもつモニタリングシステム (OSS) ‣ メトリクスに対する強力なクエリ言語 (PromQL) ‣ 動的なクラウド環境に向いているため流行りつつある •クックパッドでは 2017 年ぐらいから徐々に導入

Slide 75

Slide 75 text

コンテナ コンテナ サーバ サーバ 見つけて
 取りに行く Alertmanager ルールに基づいて クエリ アラート ダッシュボードを
 見る クエリ モニタリング/アラーティング概観

Slide 76

Slide 76 text

hako-console Slack チャンネル を設定 Alertmanager レシーバを設定 Check Fire 通知 Validator ルール設定 実装 通知先を取得 Fire システム Pull 開発 Validate Hako を中心としたアラーティングプラットフォームの図

Slide 77

Slide 77 text

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

Slide 78

Slide 78 text

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

Slide 79

Slide 79 text

Runbook #wangan

Slide 80

Slide 80 text

Runbook = アラート対応手順書

Slide 81

Slide 81 text

開発者自身も
 アラート設定できる
 (もちろんレビューする)

Slide 82

Slide 82 text

hako-console Slack チャンネル を設定 Alertmanager レシーバを設定 Check Fire 通知 Validator ルール設定 実装 通知先を取得 Fire システム Pull 実装/設定

Slide 83

Slide 83 text

What’s next? •デプロイ、サービス間通信、リソース管理、モニタリング、アラー ティングは移譲が進んできた (2019 年) •この先どうやってアプリケーション開発者と SRE で “運用” 
 するべきなのか ‣ 本番環境でエラーが出ていたら誰がどう対処するべき? ‣ ユーザにどれぐらい影響があったか (ビジネスインパクトは) ? ‣ 機能開発の手を止めて信頼性の改善に集中すべき?

Slide 84

Slide 84 text

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

Slide 85

Slide 85 text

運用シナリオ① システム システム ①エンバグ ①エンバグ ②帰宅 ②帰宅 ③アラート ③アラート ④オンコール対応 •Dev: 機能優先で信頼性をおろそかにしてしまう ‣ アプリケーションコードの品質の低下 •Ops: アプリケーション起因のアラート対応 ‣ ドメイン知識がないままバグを修正することになり
 消耗

Slide 86

Slide 86 text

運用シナリオ② システム システム 慎重な開発 慎重な開発 デプロイ デプロイ

Slide 87

Slide 87 text

運用シナリオ② システム システム 慎重な開発 慎重な開発 デプロイ デプロイ •Dev: 障害を恐れた慎重な開発 ‣ 機能リリース速度・回数の低下 •Ops ‣ サービスが成長しないのでやれることがない…

Slide 88

Slide 88 text

•価値を提供したいだけなのにどうして… 消耗 (again) Dev Ops

Slide 89

Slide 89 text

どうすれば…? •信頼性リスクを 0 にするのは不可能なことを思い出す ‣ “Everything fails, all the time.” •Dev も Ops も障害を “受け入れる” ‣ どれぐらい “受け入れられるか” を定義する • 例: サービスが 10 分落ちたらいくら損失するか?

Slide 90

Slide 90 text

SLI と SLO •サービスレベル指標 (SLI) ‣ 例: Uptime •サービスレベル目標 (SLO) ‣ 例: 月の Uptime: 99.95% (= 月に 22 分落ちてもいい) ‣ Biz, Dev, SRE すべてで共通する目標

Slide 91

Slide 91 text

SLO があると嬉しいこと •数値に基づいた具体的なコミュニケーションができる ‣ 「サービス落ちるとまずいんで落とさないようにしてく ださい!」みたいなのが無くなる ‣ SRE は必要十分なコストを払って信頼性の担保する動機 ができる

Slide 92

Slide 92 text

アプリケーション開発者の今後 •(当然) アプリケーションコードを書く •宣言的にインフラの設定を書く ‣ インフラは抽象化され誰でも触れるように •サービスレベルに従って開発・運用していく ‣ “DevOps”