[レポート] Treasure Data様と合同でSRE勉強会を開催しました

2017年11月17日（金）にTreasure Data様と合同でSRE勉強会を開催しました。

本記事はTresureData様、SREチームの発表のレポートとなります。

SREとは

Site Reliability Engineeringの略で、そのまま訳すとサイト信頼性エンジニアリングとなりますが、個人的には

• システムを運用しつつ
• 広い視点から運用をさらにどんどん改善していくエンジニア（および技術）

というすごくざっくりとした理解をしております。

参考

• Google - Site Reliability Engineering
• インフラチーム改め Site Reliability Engineering (SRE) チームになりました - Mercari Engineering Blog
• Site Reliability Engineering （SRE）ー 社内勉強会を開催しました。（前編） ｜ Developers.IO
• Site Reliability Engineering （SRE）ー 社内勉強会を開催しました。（後編） ｜ Developers.IO

以下は弊社事業開発部のSREチームの紹介記事となります。

• 事業開発部 SREチームの紹介 ｜ Developers.IO

BUILDING RELIABLE SERVICES（レポート）

発表の概要

Treasure Data社のSREチーム、Chris Maxwell様の発表です。

Treasure Dataは顧客の巨大なデータプラットフォームとなるサービスです。

• 1秒に100万回のイベントが発生し
• 1日に40万件のクエリが発行され
• 46個のサービスがあって
• デプロイ対象が280個ある

とのことで、なかなかSREの役割が重要そうです。

発表の概要は、

• SREとしての活動で求められるものは何か？
• それを実現するためにはどうすればいいか？
• 具体的にどう運用しているか

についてです。

サービスの運用にあたって何をすべきかについて、当たり前に見えることでも細かく定義することで方針や各自のタスクの決定が明確になるということを改めて学びました。

レポート

信頼性とは？

• 信頼できる状態
• 一貫して動作する

事に対する質の事である。

• システムがいつでも同じように動く事
  • 同じインプットに対しては同じアウトプットとなる事
    • もし異なるアウトプットが出ると顧客は疑問をもつし、データを信用できないし、クレームに繋がる
    • つまり、信頼できて一貫した整合性のある動作＝信頼性

インシデントについて

• インシデントとは予期していない投資である。
  • インシデントに対しては、システムの修復に時間や労力を使うので、他のやりたい事に対して使う工数を割く計画が必要
  • インシデントを避けるためにクリティカルパスを最小化する
  • インスタンスやオペレーション間の依存はインシデントの原因になりうる
    • シンプルに保つ事でリカバリーに対する時間が削減できる
    • サービスに影響を与える前にコンポーネントを修復できる

ミッション

• 各要素を一貫させる
  • サービスが同じように見えるようにする
    • エンジニアが文脈なしにシステムを使えるようになる
• 簡単に理解できるようにする
  • サービスを理解しやすくすると新しいエンジニアがサービスの理解に使う時間を減らせる
• 繰り返しできる事
  • ミスのないオペレーションには訓練と繰り返しが必要
    • 1年に5回のようなデプロイはうまくいかない
    • 大量のチェックリストやダブルチェックをするようになる
    • 自動化して1日に複数回のレベルでデプロイができるような状態にする

サービスの評価について

デプロイの対象

• サービスをどこで提供する？
  • 定義を明示的にする
    • どのインフラサービス？
    • どのリージョン？
    • どのサービス？
    • どのステージ？（開発環境？本番環境？）
    • どういう組み合わせのデプロイ？
• サービスをどのように提供する？
  • コードと設定を1つのパッケージにまとめる（Artifact）
    • アプリケーションの動作に関する設定はプロダクトのチームが提供
    • 環境に関する設定と接続情報などのシークレットはインフラチームが提供
    • 実行時に設定をまとめる
    • コードと設定を組み合わせて管理することでロールバックなどもしやすい

オーケストレーション

• アーキテクチャ
  • インフラは使い捨てる
  • オーケストレーションのためのコンテナによるオートスケール
  • デプロイのオーケストレーションのためのCodeDeploy
  • 適切なシャットダウン
• Artifact対象の作成、デプロイ、デプロイの削除、スケールなどを管理できるアーキテクチャ

ヘルスチェック

• 何を持ってサービスが動いていると判断するか
  • 全ての要素をカバーすることはできない
  • ヘルスチェックの基準を可視化する

メトリクス

• 前と同じように動いているか？
• どのように動くべきか？
• 今どのように動いているか？
• 期待される動作が明示的になっている必要がある

アラート

• 失敗とは何かを定義する
  • どれくらいの失敗を許容するか（回数、頻度）
  • リカバリーは何回まで行うか

ログ

• ログは未来を理解するための投資である
• 開発者がすぐに見れるようにする
• 文脈がわかるレベルの十分に詳細なログが必要

本番環境で起きた出来事から学ぶ

• 本番環境はステージングとは違う
  • 本番環境には本番で動いているデータが入っている

信頼性のない部分を探す

• 本質的な問題を探す
  • 顧客が気にするのは正しく動作しているかどうかであり、中で何が動いているかではない
• 実行中のタスクはどうか？
• どれくらい時間がかかるか？
• どれくらい失敗しているか？

顧客のフォローのためのメトリクス

操作について

• 操作が完了するまでにどれくらいかかるのか？
• 普通はどれくらいかかるのか？
• 標準的な操作を計測する

ジョブについて

• ジョブの時間はどれくらいかかるのか？
• 取り込みの時間を計測する

リソースは使い切るべき

• CPU、ロードアベレージは高ければ高いほどコスト的にメリットがある
  • しかし、顧客やサポートチームにとってプラスになることではない
    • バランスを取る必要がある

安全を守るために

• 人がミスをすることを前提にする
• 人が100%正しい判断ができることを前提にするのはよくない
• 期待される動作をデフォルトにする
  • 質問されたらデフォルトを変えるかドキュメントを適切に変更する

計画

• 必要最小限の製品を目指す
• コアとなるアイデアを試し、何が必要なのか学ぶ

どう作るか？

• サービス、組織間のインターフェースの定義や前提を明確にする
• 実装を切り替えられるようにする
• シンプルに保つ
  • サービスやレイヤー間が依存していると複雑になる
    • 理解できなくなっていく

感想

• とにかく自動化して人のタスクを減らすためにどうするか考える
• 自動化しづらい部分をどう自動化すればいいのか考える
• 人間がやる必要のある仕事は仕事そのもの以外の理解にかかる時間を最小化する

ことが重要なのだなと思いました。

また、勉強会後に「サービス、組織間のインターフェースの定義や前提を明確にする」ためのドキュメント作成は

• めんどくさい
• 時間がかかる

などの理由で、ルール化されても作られなかったり、いつしか更新されなくなるので「それは必要なタスクである」という雰囲気や文化を作るのが必要だと思うが、そのために何かしていることはあるかと聞いてみたところ、

• なぜそれをやると嬉しいのか説明し、メリットを理解してもらう
• チームに参加して実践する
• 実際に役に立った実例を作っていく

ことで、少しずつ改善されていく、という話をいただきました。

銀の弾丸はないけれど、適切な行動をすれば改善はされていくという話を受けて、私も粘り強く実践していこうと思いました。

私からは以上です。