SRE Lounge #8 のメモ
Cookpad社で開催されたSRE Loungeの第8回目のメモです。
ソラコムAPIの裏側で運用チームは何をやってきたのか
ソラコム五十嵐さんの発表
この記事の内容は下記ページに記載されている模様 blog.soracom.jp
- 肩書はSREではなくOpsDev Engineer
- 運用管理ツールを開発するエンジニア
- 各コンポーネント間の連携を意識しなくてOKな設計になっており、いつでも再起動可能で運用コストが低いとのこと（羨ましい）
- なのでゴリゴリ機能追加できて、2週間に1機能リリースしてるとか
- 役割分担は下記のようになっている。
- Dev： 開発、メンテ、運用（DevがOpsをやっている）
- OpsDev： 運用作業省力化、監視とか
- hubbleという監視ツールは自動で対象インスタンスの監視項目を認識
- SSHどうしてもしたいという人は出てくる...
- Slackにアクセス元IPのリストが出る
- そのリストを踏み台のSGに反映
- というようなアクセス制御をしている
- スラッシュコマンドとして"/tel <ニックネーム>"というものがあり、twillio + lambdaで電話発信する仕組みがあるとのこと
- 電話に出なかったら次の人に電話がかかるので、ほぼほぼPagerDuty
- 監視を行うラズパイのタワー（RPi Tower）というのがあるらしい
- PythonのUnittestを使っているとか
- SRE人材の傾向をJDから分析したものが紹介されていて興味深かった
Cookpad Microservice Architecture Overview
@rrreeeyyy さんの発表
#srelounge で喋った資料です https://t.co/UVLKzgk11v 行けるかなと思ったら意外と詰め込まれてて駆け足で申し訳なかったです！資料を見返してもらったり懇親会で聞いてもらったりしてもらえればありがたいです...！
— れい (Yoshikawa Ryota) (@rrreeeyyy) 2019年3月13日
- 要員はJP10名、Global4名（UK）
- 多く見えるけどサービスも増えているのでそんなでもないとか
- 世界最大のRailsアプリ -> microservice化を推進
- RRRspecは完走するようになったのでやめたらしい
- SREがボトルネックにならないようスケールさせるための取り組み
- 人をスケールさせるにはセルフサービス化が重要
- hakoでアプリケーション定義管理とかをしていて、Devが定義を書く
- SREチームはレビューをすることもないそう（おかしくなってもDev側のチームで影響が出るだけなので自己責任）
- Terraformはまだレビューが要るとか
- サーバはAutoScalingするようにする
- コスト削減のために共通基盤のSpot化（EC2の70%くらい）
- 人をスケールさせるにはセルフサービス化が重要
- Availabilityを向上させるための取り組み
- Chaos Engineeringやってる
- Envoyで遅延挟むとか
割れ窓理論をWebインフラの改善に活用し、チーム内の知識共有を促進している話
はてな id:hokkai7go さんの発表
下記ブログの内容について blog.hokkai7go.jp
- 割れ窓理論とは
- 環境犯罪学理論
- ゴミが散らかったりしないように環境を保つのが大事
- pixiv insideの割れ窓理論を参考にしたらしい
- SRE要員は部長、テックリード、メンバー、アルバイトがいるらしい（人数非公開）
- チーム付きのSREも存在するらしい
- 技術的負債の返済としての取り組み
- ドキュメントみんな書いてくれるけど古かったりする（あるあるですね）
- issueに割れ窓ラベルをつけておき、1時間/週で潰していく
- 対象は下記
- ソフトウェア
- 設定
- AWSリソース
- アラート
- 効果としては割れ窓タイムがないと取り組めないことが取り組めたり、知識共有の推進につながったとか
- 一方失敗としては長すぎるとダレる（2時間とか）
ミドルウェアのバージョンアップとか、不要な設定アラートの削除とか、なかなか優先度が上がらず放置しがちなタスクを重点的に潰す感じかな。こういうの負債が多いとテンションが下がるし、凄い良い取り組みだと思った。
まとめ
人が集まりにくいということは、その分効率化（or オフロード）してリソースを空けないといけないということなんだろうな、と思った。
それと、割れ窓タイムすぐにでもやりたい気持ちに。
