- 勉強会タイトル
- 【TD Presents】 「信頼性x大規模」サービスを運営する会社が語る！サービスを安定的、かつ、スケーラブルに運営するための技術事例勉強会 〜インフラ/SRE編〜
- 登壇
- Building reliable services
- prismatix SREチーム立ち上げからの1年間
- スマートニュースの進化の歴史
- 世界最大のレシピ動画サービス「クラシル」を支えるインフラ
Building reliable services by Chris Maxwell (Tresure Data)
- 登壇者
- Chris Maxwellさん
- Treasure Data
- 英語についていけず撃沈
prismatix SREチーム立ち上げからの1年 by 望月政夫 (クラスメソッド) @Canelmo
-
登壇者
- 望月さん
- prismatix SREチームリーダー
-
prismatixとは
- ECとCRMのためのAPIプラットフォーム
- 2016/5 開発開始
- 2016/12 本番提供開始
- 2017/1 SREを1人チーム
- 現在3名体制
-
システム特性
- スパイクアクセス
- 予測可能/予測不可能な大量アクセス
- 予告済みのセール
- ＳＮＳ砲
- 在庫洗替
- 予測可能/予測不可能な大量アクセス
- 商品検索
- ユーザは商品を探しにくる。
- メイントラフィック
- 大きな負荷、大きなNetwork I/O
- ユーザは商品を探しにくる。
- 注文・決済
- 確実性、信頼性が求められる
- 何かあったときのトレーサビリティ
- 技術
- Java8,Sprint,docker
- ElasticsearchService
- Amazon Kinesis
- Amazon RDS for MySQL,Aurora
- AWS DynamoDBD
- Redis(ElastiCache)
- JOIN時のアーキテクチャ
- ElasticBeanstalk
- マイクロサービス
- KinesisStream->Lambda->ElasticSearch
- シングルテナント
- クライアントごとに個別の環境をセットアップ
- AWSアカウントも独立させる
- 新規案件が増えるたび、環境が増える
- セキュリティを高めるため
- SREのミッション
- 環境が増えても、管理コストを増やさない
- スパイクアクセス
-
デプロイ
- JOIN時
- Elastic Beanstalk
- GitHub + CircleCIで開発
- 開発者が個人の端末からデプロイ
- デプロイはCloudFromationを利用
- インフラからアプリケーションまでを一括で管理
- 課題
- CloudFromationのパラメータ定義が各個人の端末にあって、だれのがマスターにあるのか不明
- 誰かがパラメータ操作したものを知らずにデプロイすると事故る
- 改善:完全に再現可能なインフラにする
- セットアップ内容を完全に自動化する
- 環境毎の差異が発生しないようい
- 何かあればrebuldできるという安心感
- インフラのテスｔおにも使える
- 改善:デプロイ方法の見直し
- Beanstalkからamazon ECSへの移行。環境変数の扱いを安全にする
- 環境変数をSSM Parameter StoreとDSLで管理
- デプロイツール上で環境変数のInjextion / overrideを行う
- 誰が実行しても安全な結果になるようにする
- JOIN時
-
これからやりたいこと
- インフラレイヤを含めたCI&テスト
- ゼロから環境をセットアップ
- その上にアプリケーションデプロイ
- テストが終わったらteardown
- インフラレイヤを含めたCI&テスト
-
監視
- JOIN時はZabbixのみ
- 取りたいメトリクスが取り切れていなかった
- DataDogの利用を開始
- AWS IntegrationとDocker Integrationが便利
- 複数のAWSアカウントの管理に対応している
- 監視対象
- 基本的なCloudWatchメトリクスとOS上メトリクス
- SLAとSLO
- API可用性
- レスポンスタイム
- ジョブの実行速度
- なにかあったらSlack通知
-
ログ
- JOIN時
- 全ログをBeanstalkからCloudWatch Logsに転送
- いま
- 各コンテナのfluentdから2箇所に転送
- ロードバランサー(経由でCloudWatchLogsへ)
- S3(何かあったときのため)
- 各コンテナのfluentdから2箇所に転送
- CloudWatchLogsは結構なお値段
- しかも必要なログはわずか
- ということでAmazon Athenaを使い始めた
- いま
- CloudWatch Logsには通知が必要なエラーログだけを送る
- S3にすべてのログを保存、必要に応じてAthenaにSQLで検索
- Athenaはパーティション切手。そうじゃないとフルスキャンになって高くなる
- 月ごとにパーティション切ってる。
- Athenaの同時接続数がデフォルトは5なので注意
- Athenaなら別のAWSアカウントのS3にアクセスできる
- JOIN時
-
これからやりたいこと
- Prometheus導入
- ログ検索のリアルタイム性向上
- 現状はS3に入っていないといけない
-
まだ立ち上がったばかりのチーム
- 組織小さい
- まだ泥臭い運用が多い
- 自走するシステムを目指す
-
質疑応答
- CREDENTIALの管理は？
- マルチアカウントの管理は？
- 複数のAWSアカウントにアクセスできる内製のツール
- そのツールを使えばAWSにReadOnlyでログインできる。
- デプロイのタイミングはテナントごとに違う？それとも同時？
- テナントごとに違うスケジュールが組まれている。
- なのでテナント毎にバージョンが違ったりとかもある
- ElasticSearchの性能劣化があるのでツライ印象だが、どうか。正直なところAWS ElasticSearchServiceはアンチパターンだと思うが…
- ツライことはある
- Full Kubernetesでもいいと思ったが、どうか。シングルテナントだとそのうちつらくなるのでは。
- AWSのフルマネージドサービスを使うという前提があったので今の構成になっている
- 今後はEKSも使うかも
- CREDENTIALの管理は？
スマートニュースの進化の歴史
- 登壇者
- 真幡康徳さん(スマートニュース)
- ニュース配信基盤担当
- ややインフラ寄り
- TDのChrisさんとは前職の同僚
- 創業期のアーキテクチャ
- モノリス
- クロール、分析、インデクサ、メモリ、API
- モノリス
- 今は進化している
- スマートニュース特有のチャレンジ
- 日米で開発拠点が分散している
- 言語、タイムゾーン、空気感の壁
- 言語の壁
- がんばるしかない
- slackチャンネルで-EN,-JAをつけて区別していたりはしている
- Qiita:teamもタグで日本語ものに、英語のものがわかるようにタグで区別されている
- ボットのローカライズ？
- 翻訳ボット
- google translation api + hubot実装
- けものフレンズはハイコンテキストすぎて却下された
- 翻訳ボット
- がんばるしかない
- 時差のかべ
- 相手のタイムゾーンを意識するツール
- カレンダーで2タイムゾーン表示
- clockerも
- 相手のタイムゾーンを意識するツール
- 半年に1度は海外ワーク。スマニューなら旅費もカンファレンス費もすべて負担
- 米国オフィスに出張
- 日米で開発拠点が分散している
- インフラの構成管理
- 避けたいこと
- Dev(新しい機能を作ること) vs Ops(サービスを安定させること)
- Dev
- コードを書くことでインフラを設定
- Ops
- コードレビューでインフラの安定化
- もちらん自身もコードを書く
- Dev
- Dev(新しい機能を作ること) vs Ops(サービスを安定させること)
- ツール
- インフラ作成 Terraform
- プロビジョニング Itamae + Fabric
- IaaSとエンタープライズ契約
- AWSとエンタープライズ契約をしている
- 利点
- 雑に質問していい
- 必要な情報は「先方が」教えてくれる
- 普通は知り得ないことを教えてくれる
- VMが載っているホストの譲歩うとか
- 普通は知り得ないLimitを教えてくれる
- ELBスパム認定されてしまった事件
- 雑に質問していい
- 利点
- AWSとエンタープライズ契約をしている
- 避けたいこと
- マイクロサービス
- いい話
- サービス分割
- サービスごとに違う技術を選択可能
- サービスごとにチームを分割可能
- サービスごとにスケール可能
- 小さい単位でのリリースが可能
- サービス分割
- 悪い話
- サービスごとに違う技術を選択可能
- サービス間での技術の流用が困難
- チーム間での技術共有が困難
- サービスごとに違う技術を選択可能
- 落としどころ
- 新サービスの作成がベストか疑う
- サービス＆エンジニアを1:1にしない
- サービスごとにチームを閉じない
- いい話
- 社内コミュニケーションHacks
- 勉強会は目につくところで開催する、資料公開する
- 寿司にひかれてやってくる別分野エンジニア、かきねをなくす効用
- この手の勉強会に予算をつける
- オフィスの端から端まで移動しなければいけない作りになっている
- これから解決すべき問題
- システム障害に強くする
- 適切なメトリクスの取得
- 適切なアラートの設定
- 適切なタスクアサインメント
- …
- on-callローテで解決できる？
- 採用
- システム障害に強くする
- 質疑応答
- カオスエンジニアリングはやっているのか
- カオスエンジニアリングはやってない
- 残念ながらカオスモンキーに頼らずとも色んなことが起きる（汗）
- カオスエンジニアリングはやっているのか
世界最大のレシピ動画サービス「クラシル」を支えるインフラ
- 登壇者
- 深尾さん(Dely)
- 元料理人
- 25歳でエンジニアになる
- クラシル
- レシピ動画数世界No.1
- 広報がやたら優秀
- 一人目のSRE
- 2016年12月のJOIN時はWeb,DBはシングル構成、監視未整備、ログ収集/分析基盤未構築、バックアップなし、キャッシュは一部
- 限られたリソース
- 技術・設計
- スケーラビリティ
- スケールアウト(負荷分散)
- 負荷テスト
- 台数増やしても処理量が増えない感じになっちゃってないか計測、そうなっていれば原因をつぶす
- サイジング
- スケールアウトできないもの
- RDB,ジョブ
- スケールアウトできないもの
- 可用性
- 単一障害点をなくす
- バックアップ
- 自動復旧
- モニタリング
- サービス/リソース監視
- サチュレーション(CPU,メモリ、I/O,空き容量)
- サービス/リソース監視
- キャッシュ
- memcached,nginx,CDN,Elasticsearch
- プロトコル
- SSL(ACM,let’s encrypt)
- gzip
- http/2
- パフォーマンス＆コストに影響
- 変更に強い設計
- ログ収集基盤
- データ設計に伴う変更が不要
- fluentdのforestプラグインを使い、どのＵＲＬに送るかを変更することで対応できるように
- データ設計に伴う変更が不要
- 構成管理
- コード化＆DRY原則
- 半年で作り直す覚悟
- ログ収集基盤
- スケーラビリティ
- 運用
- サービスレベル目標(SLO)
- 全アラートに対応しなければならないのか？
- 信頼性をあげる作業には終わりがない->どこまでやるかを決める
- 減点方式から目標達成方式に転換
- SLOを決めるにあたって
- ユーザ目線
- すでに取得できている指標や拾得しやすい指標を使う
- 今のパフォーマスを基準にしない
- 設けてある目標
- API稼働率
- レイテンシ
- infrastructure as Code
- DRY原則
- ツールやFWは任意
- タグで管理
- 論理名と物理名
- 論理名: 「webサーバ」のような役割ベースの呼び方
- 物理名: aliceのような固有の名詞
- DevOps
- デプロイは自動化
- 開発者自身がデプロイ
- ロールバック
- かなりあリリース
- ChatOps
- イベント対応
- 広報カレンダー
- テレビ露出いっぱいあるけど
- コミュニケーションロス
- なんでスケールしてないの？
- テレビ露出いっぱいあるけど
- イベント対応レベル
- レベル1: 通常運用
- …
- レベルx: めっちゃ対策しといて
- Webトップページを守る
- 予期せぬトラフィック発生時
- トップページが落ちたことがある
- 新規ユーザ獲得のチャンスを逃す
- 予期せぬトラフィック発生時
- 広報カレンダー
- インシデント対応
- オンコール担当
- インシデント責任者
- トリアージ
- インシデントチャンネル
- ポストモーテム
- 書くこと
- タイムライン
- よかったこと
- 悪かったこと
- 幸運だったこと
- 根本原因分析は必要な場合だけ(限られたリソースなので)
- 再発防止策はIssue追加
- 犯人探しはしない
- 書くこと
- TODO管理
- TODOはIssue作成
- タスクは自分から拾う
- SREミーティングで棚卸し
- サービスレベル目標(SLO)
- マネジメント
- SRE Principles
- ミッション
- サービスの信頼性を確保する
- 意思決定に必要な指標を取得し正確であることを保証する
- 開発部の生産性を高める
- SLO運用方針、判断基準
- Principlesの背景
- 主体的に行動できるように
- 得意分野を活かす
- 心理的安全性(細かく決め過ぎないことで)
- Whyを共有
- なぜやるのか
- Whatを共有
- 何をやるのかを共有
- Howは決めない
- 使用言語や技術は自由
- やり方に口を出すことは心理的安全性を脅かす
- Whoは決めない
- 誰かがアサインするのではなく、自分からタスクを拾う
- それぞれが得意な分野を活かす
- モチベーション
- Whenは決めない
- ミッション
- SRE育成にAPOLLO Program
- 障害対応訓練
- SRE Principles