3月15日に行われた、【TD Presents】「信頼性×大規模」サービスを運営する会社が語る！ サービスを安定的、かつ、スケーラブルに運営するための技術事例勉強会 ～インフラ/SRE編～に参加してきました。
会場はTECH PLAY SHIBUYAでした。渋谷だったので徒歩で行けて便利でした。
開始前から軽食ビュッフェが提供されており、とても美味でした。懇親会でしか食べられないと思ったので前もって食べてきたのは失敗でした。。。
- Building reliable services
- prismatix SREチーム立ち上げからの1年間
- スマートニュースの進化の歴史
- 世界最大のレシピ動画サービス「クラシル」を支えるインフラ
- 最後に
Building reliable services
Chris Maxwellさん
Treasure Data, Inc. Site Reliability Manager
Reliability is the quality of being trustworthy or of performing consistently well. With standards, exceptions are hard; without standards, everything is hard. At Treasure Data we are improving and standardizing our services across hundreds of deployments to improve overall service and system reliability.
私の英語力が皆無でほぼ聞き取りができず、かろうじて聞こえたメモも大した内容じゃないので公開しません。勉強します。。。
prismatix SREチーム立ち上げからの1年間
望月政夫さん
クラスメソッド事業開発部 SREチームリーダー
クラスメソッド事業開発部では「ECとCRMのためのAPIプラットフォーム」をコンセプトに、prismatixという製品開発に携わっており、日々多くのリクエストを捌いています。SREチームが発足した2017年1月から、サービスの安定化と運用自動化のためにどういう取り組みをしてきたかをお話しします。
prismatixの紹介
- ECとCRMのためのAPIプラットフォーム
- ECとCRM(ポイント機能など)の機能をAPIとして提供
アーキテクチャについて
- システム的特性
- スパイクアクセス
- 予測可能/不可能な大量アクセス
- 商品検索
- ユーザは商品を探しにくる
- 商品検索がメインのトラフィック
- 注文/決済
- お金まわりは確実性・信頼性が求められる
- 完全なトレーサビリティ
- 技術スタック
- Java8 + Sprint Boot + Docker
- 商品検索はAmazon Elasticsearch Service
- Amazon Kinesis
- AWSマネージドサービスを多用しているが適材適所で選定している
- シングルテナント
- クライアントごとに個別の環境をセットアップ
- AWSアカウントも独立している。案件が増える度に環境も増える
- セキュリティを高めるためだが、アカウントの管理が面倒
リリースとデプロイ
- JOIN時のElastic Beanstalkで利用
- 開発者が個人端末からデプロイしていた
- デプロイはCloudFormation。インフラからアプリまで管理
- CFのパラメータ定義が各個人でバラバラでマスタが不明。誰かがパラメータ操作していると危険
- シングルテナントなのでセットアップを完全自動化し環境毎の差異が発生しないようにした
- デプロイ方法の改善
- Amazon ECSへ移行
- Circle CIからビルド時にImageをPush
- 環境変数をSSM Parameter StoreとDSLで管理
- デプロイツール上で環境変数のInjection/Overrideを行う
- 誰が実行しても何度実行しても同じ結果になるようにした
これからやりたいこと
- インフラレイヤを含めたCI & テスト
- ゼロから環境をセットアップ
- アプリケーションデプロイ
- テストが終わったらtear down
- Elasticsearchインデックス再構築の高速化
監視ツール
- JOIN時はZabbixのみ。取りたいメトリクスが取れなかった
- DataDog
- Dockerのメトリクスなど自動で取得してくれる
- 複数のAWSアカウントも対応している
- CloudWatchメトリクスとOSのメトリクスを監視
- SLAとSLO
- API可用性
ログ周り
- JOIN時はCloudWatch Logsに送信
- Beanstalkの機能でS3に退避
- 取り切れないログがあった
- すべてのECSにFluentdに置く
- ELBとS3それぞれにログを転送
- S3はログをロストしないため
- CloudWatch Logsは意外と高い
- 必要とされるログは全ログの1%未満(分析は除く)
- 現在は通知が必要なエラーログ通知 (SNS経由)
- Amazon Athena
- アプリログはすべてJSONで出力している
- S3にすべてのログを保存して、必要に応じてAthenaで検索している
- 月初に月ごとパーティションを作成するバッチを実行(ECS Scheduled Task)
- 他のAWSアカウントのS3バケットもポリシーを設定すれば検索できる
- 今後はPrometheusを導入したい
- ログ検索のリアルタイム性の向上
- S3に入っていないと検索できない
- APMの導入(NewRelicとか)
Q&Aなど
- クレデンシャルの管理
- 環境毎にParameter Storeに保存
- AWSのマルチアカウント管理ツール
- クラメソの自社ツール。これがないとつらい
- アカウント一覧がでてきて、クリックするとそのアカウントにReadOnlyでログインできる
- CloudTrailのログも各環境ごとに保存
感想
AWSといえばクラスメソッドさんですね。基本的にAWSマネージドサービスを多用されています。シングルテナント構成なので膨大なAWSアカウントの管理は自社ツールで行っているのはさすがです。
スマートニュースの進化の歴史
真幡 康徳さん
スマートニュース株式会社 Software Engineer
2012年12月にリリースしたスマートニュースは、昨年10月には世界で2500万ダウンロードされるまでに成長しました。 ここに到達するまで色々な課題にぶつかり、それらをひとつひとつ乗り越えることで組織として成長してきました。今回は、わたしたちが成長の過程で学んだことのうち、「日米のマルチリージョンで開発をするために必要なこと」と「スケールする開発体制を作るために必要なこと」についてお話をしようと思います。
スマートニュース特有のチャレンジ
- 日米で開発拠点を分散させる難しさ
- 言語の壁
- Slackのemoji
- Qiita:Teamのタグづけ(
tag:english) - タイムゾーンの壁
- Clocker ･･･ 相手のタイムゾーンを意識するツール
- 空気感の壁
- 半年に一度海外拠点への旅費を補助してくれる
構成管理
- Dev vs Opsは避けたい
- Dev: コードを書くことでインフラを設定
- Ops: コードレビューでインフラの安定化。コードも書く
- Ops => SRE
- ツール
- Terraform
- Itame + Fabric
- AWSタグ単位のプロビジョニング
- Gitブランチ単位のプロビジョニング
- dry run
- DevがPRを出してOps(SRE)がレビューする。dry-runの実行結果をPRに記載する
- 前もって変更内容をレビューできる
- Devに移譲することで、SREの負荷軽減
- 変更履歴をGitに残る
IaaSとエンタープライズ契約
- ある程度の規模を超えたら必須だと思う
- 雑に質問できる
- むしろ雑に聞いてOK
- 普通は知りえないことを教えてくれる
- VMが載っているホスト情報
- 普通は知りえないLimitを教えてくれる
マイクロサービス
- いい話
- サービスごとに違う技術が選択できる
- サービスごとにチームを分割できる
- 悪い話
- サービスごとに違う技術が選択できる
- サービス間での技術の流用ができない
- サービスごとにチームを分割できる
- チーム間での知識の共有ができない
- つらい話
- AMIの更新(脆弱性のパッチ当てなど)
- サービスごとにLCを設定すると全サービス入れ替えが発生する
- 行き過ぎたマイクロサービス
- サービス数 > エンジニア数
- あるエンジニアが退職するとレガシーコードが誕生する
- サービスとエンジニアを1：1にしない
- 新サービスの作成がベストか疑う
社内コミュニケーションHacks
- チームビルディング費用
- お寿司をふるまう
これから解決すべき課題
- システム障害に強い体制作り
- すごい人ばかり対応すると疲れて退職してしまう
感想
組織やコミュニケーション寄りのお話をされていました。マイクロサービスのところは私のところがまさにその窮地にいたっており、エンジニア:サービスが1:1で紐付いてしまっているので、誰かが退職すると他の人がメンテナンスできないというつらみが発生しています。マイクロサービスできすぎ問題に対して一般的に解決できないということでした。
世界最大のレシピ動画サービス「クラシル」を支えるインフラ
深尾 もとのぶさん
dely株式会社 Site Reliability Engineer
1000万ダウンロードを突破したクラシルの急成長を支えるSite Reliability Engineering
- JOIN時
- 一人目のSRE
- WebやDBはシングル構成
- 圧倒的にリソースが足りない
技術設計
- スケーラビリティ
- サイジング
- スケールアウトできないもの(RDB、ジョブ)
- Maxで1年耐えられる程度
- 可用性
- バックアップは大事
- S3のバージョンニングを有効にしたおかげでデータがぶっとんでも復旧できた
- Cache
- memcachedをメインでつかっている
- プロトコル
- gzip
- HTTP/2
- 変更につよい設計
- ログ収集基盤
- データ設計に伴う変更が不要になるようにする
- 構成管理
- コード化&DRY原則
- 半年で作り直すこともある
運用
- サービスレベル目標(SLO)
- APIの稼働率
- 設定していないと全部のアラートに対応することになり疲弊していく
- アラート = 悪になってしまう
- CPU使用率が高くてもSLOに影響しなければ対応を遅らせることもする
- ユーザ目線
- SLOを定めることで、減点方式から目標達成型になる
- 今のパフォーマンスを基準にしない
- トラフィックが超えた場合に基準を超えてしまう
- ユーザ目線で考える
DevOps
- デプロイは自動化
- ロールバック
- カナリアリリース
- ChatOps
イベント対応
- 広報カレンダー
- コミュニケーションロスが発生する
- イベント対応レベルを決める
- Webのトップページを守る
インシデント
- オンコール担当が受ける
- インシデント責任者になるか => ならない場合は別の人を責任者にする
- ポストモーテム
- 恒久対応
- 根本原因分析は必要な場合だけやる
- 再発防止策はIssueに追加する
Todo管理
- TodoはIssueを作成する
- SREミーティングで棚卸
- 優先度高い順から設定していく
マネジメント
- SRE Principles
- ミッション
- SLO
- やること・やらないことを決める(スコープの選択)
障害対応訓練(APPLO)
- SRE育成
- エンジニア広報
- Week1
- 本番環境と同じ環境を構築
- データはダミー
- Week2
- 障害を実際に起こす
- 例) ログ収集基盤のバージョンを上げたら動かなくなった
感想
元料理人だったという深尾さんによる発表で、具体的な現場感あふれる事例を紹介していただきました。
取り組みを多くされている一方でやらないことを明確にし、ユーザに影響が与えない範囲(アラートやインシデントなど)はやらないか優先度を下げることで負荷を減らす工夫も参考になります
スタートアップで圧倒的に資源(人・時間)が足りないなかでこれだけの取り組みをされてきているのは素晴らしいし、私も現状に嘆いていないで頑張ろうと思えるようになりました。
最後に
各社で取り組まれている多くの事例が聞けて最高の勉強会でした。問題点に対してひとつずつ解決していっており、私もやらなければ！と強く刺激されました。
