TREASURE DATA社主催のSRE勉強会に行ってきた

昨晩、こちらの勉強会にお邪魔してきました。

以下は発表概要と所感です。

※発表資料はまだ公開されていないものもあるようですが、捕捉したらなるべくこの記事にも載せます。

BUILDING RELIABLE SERVICES

TD社のSRE Chris Maxwellさん(@WrathOfChris)の発表。

Tokyo SRE Meetup - Building Reliable Services - A Journey from servers to services from Chris Maxwell

TDはかなり色々なサービスがあって、それぞれデプロイ方法や構成方法がバラバラでだいぶカオスな状況だったけど、最近スタンダードを作るようにしていて、段々よくなってきている、というような趣旨だった。

英語の発表だったけど、とてもきれいな発音で聴きとりやすかった。

prismatix SREチーム立ち上げからの1年間

クラスメソッドの望月さん(@Canelmo)の発表。

prismatixというのは、クラスメソッドさんの子会社で提供しているサービスで、ECとCRMを簡単に構築できるAPIプラットフォームらしい。
お客さん向けにそれぞれAWSアカウントを作って提供しているので、複数アカウントの管理・運用をいかに効率的にするかが肝、といった話があった。

特に興味深かったのは以下の点:

• CloudWatch Logsにはアラートに必要なログだけを入れ、全ログはS3に保存している。
  • CloudWatch Logsに全ログを保存すると高くつく
  • S3に保存していれば、バケットの参照を許可していれば一箇所からAthenaでクエリすることができる。
• 監視にDataDogを使っている。DataDogは複数AWSアカウントに対応していて便利。

あと、クレデンシャルの管理はどうしているのだろう？ と気になったので質問してみた。
これは「DSLとSSM Parameter Storeで管理していて、誰が実行しても同じ環境が構築できる」という話があったので。
回答としては、「クレデンシャル情報もSSM Parameter StoreのSecret Stringで保存している。誰がそこにアクセスできるかは別途(おそらくIAMで)管理している」というような内容だった。

スマートニュースの進化の歴史

スマートニュースの真幡さん(@mahata)の発表。

スマートニュースでのDevOpsやMicroservicesに対する取り組みについての話で、良い話だけでなくて悪い話もあって、わかりみがあった。
サービスが一定の規模を越えるとIaaSとエンタープライズ契約を結んだ方が良いというのは、個人的には頷ける話だった。

また、面白かったネタとしてSlackによるローカライズbotの話があった。
これはSlackの投稿に各国の国旗をリアクションで付けると、その投稿に対してスレッド返信の形で、その国の言語で翻訳した結果をbotが投稿するというものだ。
とても便利そうだと思った。

世界最大のレシピ動画サービス「クラシル」を支えるインフラ

delyの深尾さんの発表。

深尾さんは元イタリア料理人だそうだ。

氏がクラシルにjoinしてから、どのようにインフラの改善を行い、SRE的なプラクティスを実践しているのかを発表した。
なんでもやるわけじゃなくて、人員リソースを考慮してやる・やらないをはっきり決めているのがとても良いなと思った。

まとめ

各社のSREに関する取り組みを聞けて良い刺激を得られた。
Web系を中心に日本のテック業界にもSREのプラクティスが広まってきているように感じる。

TECH PLAYに行ったのは2回目だけど、相変わらずきれいで雰囲気の良い会場だった。

今回は軽食ビュッフェと飲み物が豊富に提供されて、飲食を楽しみながら聴講することができた。

主催してくださったTREASURE DATAさん、ありがとうございました！！

おまけ

以下は会場で取った雑なメモです。
ほとんど清書してないので、気が向いたら見てください。

Chris Maxwell @WrathOfChris

SRE

BUILDING RELIABLE SERVICES

• Why?
  • Building Reliable Services
  • cannot buy reliability
  • tools
• daily workload
  • 400,000+ queries / day
  • 1 M+ events / sec
  • 15+ Trillion Rows / day
• runtime convergence
  • cookbooks ... Chef
• Our hero
  • infra engineer & SRE
  • increase velocity
    • faster than weekly deployments
    • more sites
• complex platform
  • job control
  • java
  • Hadoop
• Service Delivery is hard
  • measure reliability
  • foundation is dirty work
• Wisdom from outsie
  • simple first
  • on experts and advice
• mentor returns
  • chunks ... 7
• first changes
  • standard deployment targets
  • standard startup services
  • Derek Coolison
• hard work ahead
• wrap up service
  • autoscale group
  • Presto
  • Simple is Hard
    • 3 sources of configuration truth
• Didn't have time for API
• 6 friends for the journey
  • Autoscaling
  • App Load Balancer
  • EC2 Security Group
  • Code Deploy
  • Route 53
  • IAM role
• More friends
  • trust team
  • Don't solve problems with software that should be solved with talking
• Mentor returns
  • tools express process
  • process should uplift the organization
• Service Tool
  • 6 infra api w/ MVP tools
    • Leverage immediate gain ... orchestration
    • paying interest ... learning team
• Services First
  • any engineer can
    • release frontend/backend
• Complexity ... enemy
  • cut & paste and grow ...
  • unclear boundaries
• Migrate
  • simplifying complex
  • many transitional changes
  • precision replacement
• Process
  • Legacy Process
  • Transition
• Standard Services First
  • With standards, exceptions are hard
• 新しいやり方でリリースできた！
• remaining services
• The way home
  • Best Practices
    • Standard services
• Remaining services
  • service improvements
  • support config management
  • strategy to improve
• heroes
  • Yuu Yamashita
  • Yuki Ito
  • Kokubun
  • Chris

prismatix SREチーム立ち上げからの1年

クラスメソッド望月

• @Canelmo
  • prismatix SREチームリーダー
  • AWS認定SA / DevOps Professional
• prismatixの紹介
• アーキテクチャー
• リリースと
• Developers.IO
• prismatix
  • ECとCRMのためのAPIプラットフォーム
  • 2016/5 開発開始
  • 2016/12 本番リリース
  • 2017/1 に1人チーム
  • 2018/3 3人体制
• システム特性
  • スパイクアクセス
    • 予測可能/不能な大量アクセス
      • 予告済みのセール
      • SNS砲
      • 在庫洗替による大量更新
  • 商品検索
    • ユーザーは商品を探しにくる
    • 検索がメインのトラフィック
    • 大きな負荷、Network I/O
  • 注文/決済
• 技術スタック
  • Java8 w/ Spring Boot + Docker
  • Elasticsearch by AWS
  • Kinesis
  • RDS for MySQL (Aurora)
  • AWS DynamoDB
  • Redis (AWS ElastiCache)
• 全文検索したいデータをKinesisに流してElasticsearch Serviceに登録
• クライアントごとに個別の環境をセットアップ
  • AWSアカウントも独立させる
  • デメリット:
    • 新規案件が増えるたび、環境も増える
• JOIN時のデプロイ方法
  • AWS EB
  • GitHub + CircleCI
  • 開発者が個人の端末からデプロイ
  • CloudFormation ... デプロイ
    • パラメータ定義を各自が個人端末で管理
    • プロジェクトJOIN時、誰かからもらう
• 改善: 完全に再現可能なインフラにする
  • シングルテナント
  • セットアップ内容を完全に自動化
  • 環境ごとの差異が発生しないように
  • 何かあればrebuildできるという安心感
  • インフラのテストにも使える
• デプロイの見直し
  • Beanstalk から ECSへの移行
  • CircleCIからビルド時にImageをPush
  • 環境変数をSSM Parameter StoreとDSLで管理
    • DSLでParameter Storeの値登録
• これからやりたいこと
  • インフラCI
  • Elasticsearch index構築高速化
• 監視ツール
  • 社内共通の監視ツール
  • 取りたいメトリクスが取りきれてなかった
  • DataDog
    • 複数のAWSアカウントの管理にも対応
  • AWS IntegrationとDocker Integrationが便利
• 監視対象
  • CloudWatchメトリクスとOSメトリクス
• ログ周り
  • JOIN時
    • EB => CloudWatch Logsに送信
    • いくつかのログはOSに入らないと見えない
  • 変更後
    • ECS Cluster
      • Log Driver -> fluentd
        • S3にログ保存
        • LBにログを飛ばす
          • fluentd
            • CloudWatch Logs
            • 他 etc
• CloudWatch Logs
  • 割りとお高い
  • 通知が必要なエラーを送る
• Athena
  • S3上のログがJSON
  • partitionを切る
    • 月ごと <= 月初にバッチで
  • 同時接続数がデフォルトだと5なので注意
  • 他のAWS S3も許可してれば見える
• 質問:
  • credentialの管理
    • Parameter Store
      • 誰が操作できるかを別途管理
  • cloudtrail logs
    • 各アカウントごと
  • Elasticsearchの性能劣化について
    • つらいことはある
  • K8s考えなかったのか？
    • AWS使う前提だった

スマートニュースの進化の歴史

• @mahata
  • Software Engineer
  • ややインフラ寄り
  • ニュース配信基盤担当
• SmartNews
  • クーポンチャンネル
• オフィス風景
• ニュース配信基盤
  • 監視
    • Data Dog
  • 配信
    • Cloud Search
  • 検索
  • 収集
• スマートニュース特有のチャレンジ
  • 日米で開発拠点を分散させる難しさ
    • 言語の壁
    • 空気感（？）の違い
• 言語の壁
  • Slackで英語で話すチャンネルを作る
    • 全員日本人でも英語で
  • botのローカライズ難しい
  • Qiita:Team
    • tag:english
  • 便利ツールまじ便利
• 半年に1度は海外ワーク！スマニューならカンファレンスも
• インフラの構成管理
  • 避けたいこと ... Dev vs. Ops
• インフラの構成管理
  • Dev ... コードを書くことでインフラを設定
  • Ops ... コードレビューでインフラを安定化。コードも書く
    • => SRE
• ツール:
  • Terraform
  • Itamae + Fabric (+ カスタム Fabfile)
• IaaSとエンタープライズ契約
  • AWS
  • ある程度の規模を超えたら必須ではないか
  • メリット:
    • 雑に質問できる
      • 必要な情報は先方が教えてくれる
    • 普通は知りえないことを教えてくれる
      • ex) VMが載っているホストの情報
    • 普通は知りえないLimitを教えてくれる
• Microservices
  • 良い話
    • サービス分割 / チーム分割
      • 違う技術を選択可能
      • サービスごとにスケール可能
      • 小さい単位でのリリースが可能
  • 悪い話
    • サービス間での技術の流用が困難
    • チーム間での知識の分断
    • /api/v1/x, /api/v2/x
  • つらい話
    • 脆弱性のあるAMI
    • 更新
    • サービスごとにLCを設定
  • 行き過ぎたMicroservices
    • サービス数 > エンジニア数
    • あるエンジニアが退職
    • レガシーコード誕生！
  • 落とし所
• 社内コミュニケーションHacks
  • 読書会 ... SRE本
  • Work Out Loud
    • 人目につくところで開催する
    • 資料も人目にふれるところに置く
    • 参加者が増える
  • お寿司
  • 勉強会に予算を付ける
• これから解決すべき課題
  • システム障害に強い体制づくり
    • 適切なメトリクスの取得
    • 適切なアラート設定
  • システム障害対応あるある
    • すごい人
• Q&A:
  • Chaos Monkeyとか使ってる？
    • 使わなくても色々起きてる

現場で使えるSite Reliability Engineering

Fukao Moto / dely

• ブンさん
  • 元料理人
• クラシル
  • 1分でレシピがわかる
  • 2017年メディア露出多い
  • 昨年末に1,000万ダウンロード
• 1人目のSRE
  • Web / DBはシングル構成
  • 監視未整備
• スケーラビリティ
  • スケールアウト
  • 負荷テスト
    • ボトルネックを見つける
  • サイジング
    • スケールアウトできない:
      • 例) RDB, ジョブ
    • ディスクサイズも1年を目安に　
• 可用性
  • SPOFをなくす
  • バックアップ
  • 自動復旧
  • モニタリング
• 監視メトリクス
  • サチュレーション
• キャッシュ
  • Memcached
  • Nginx
• プロトコル
  • SSL (ACM, Let's Encrypt)
• 変更に強い設計:
  • ログ収集基盤:
    • fluentd + forrest
  • 構成管理
    • コード化 & DRY
• SLO
  • なぜSLOが重要か？
    • 全アラートに対応？
    • 信頼性をあげる作業には終わりがない
    • 減点方式から目標達成方式に転換
• どうやってSLOを決めるか
  • ユーザ目線
  • CloudWatch Metrics
    • パーセンタイル値
• Infrastructure as Code
  • DRY原則
  • ツールやFWは任意
  • タグで管理
  • 論理名と物理名
• DevOps
  • カナリアリリース
  • ChatOps
• イベント対応
  • Webのトップページを守ろう
    • スマステ
      • 予期せぬ数十万UU
      • 新規ユーザ獲得
      • 遅いページで全体が詰まる
    • Nginx
      • pathによってupstreamをグルーピング
      • cache
  • コミュニケーションロス
    • イベント対応レベルを決める
• ポストモーテムに書くこと
  • タイムライン
  • 良かったこと
  • 悪かったこと
  • 幸運だったこと
  • 書かないこと
    • 根本原因分析
    • 再発防止策 => Issueに
    • ※犯人探しはしない
• TODO管理
  • Redmine
• SRE Principles
  • 主体的に行動できるように
  • 得意分野を活かす（生産性）
  • Why, Whatを共有
    • 3W, 1Hはあえて共有しない
      • Whenは決めない。Whyがわかってれば優先順位はわかるはず
    • 何をやらないかを定義 ★
• ミッション
  • 意思決定に必要な指標を取得し、正確性を保証する
• SREミーティング
  • 会議コストを最小化
  • アジェンダを事前共有
  • 週次/隔週/月次
  • 金曜に実施 ... 週末に準備できる
• リスクマネジメント:
  • 何もやってないとまずい
  • 小さなコストで大きなリスク
• APOLLO Program
  • 障害対応訓練
• まとめ
  • 費用対効果を重視
  • スケーラビリティの確保
  • スコープ ... やらないことの選択
  • WHYを共有
• Q&A
  • 障害対応の再現方法
  • 根本原因を調べないと再発防止できないのでは？
    • 根本原因を調べることもIssueにする