インフラ未経験者がSREチーム立ち上げのために1年間やってきたこと
ざっくりいうとフロントエンド開発歴2年、サーバーサイド開発歴2年
インフラ未経験の私がいきなりSREチームを立ち上げることになり奮闘した記録です。
会社によってSREチームの定義や役割は変わると思いますので、あくまで一例として捉えてもらえると幸いです。
はじめに
サイト信頼性エンジニア(SREエンジニア)とは、それはもうレベルの高いロックスターなシステムエンジニアのことなので
私はSREエンジニアと名乗れるほどの者じゃありませんし、どちらかというとソフトウェアエンジニアです。
ただ、誤解を恐れずに言うとSREはエンジニアリングを以ってインフラ的課題を解決する手法だと思っているので ソフトウェアエンジニアがコミットメントできる側面もあると思います。
立ち上げ時の状況としては以下
- Webメディアを運用している中規模の会社
- 社内にインフラエンジニアはいない
- インフラ系タスクのうち8割以上をMSP事業者さんにお願いしている
- 立ち上げ時の体制は私と業務委託の2名体制
課題感
- インフラ領域の大半をMSP事業者さんにお願いしているため社内にノウハウが貯まらない
- アラートが効果的ではないため障害復旧に時間がかかる
- サーバー設定まわりがブラックボックス化しているため、ローカル・検証環境での再現性が低い
役割の整理
まず、現状できていることとSREチームとしてやる必要があることの整理をしました
- これまでのインフラの役割（現状できていること）
- SREチームならではの役割（やる必要があること）
- コード化・自動化
- ローカル開発環境の整備
- デプロイフロー構築
- アプリケーションの品質管理・可用性の向上
- テストフローの構築
何をやったのか
対応の優先度づけやロードマップについては割愛しますがこれらを試しました
- Terraform, Ansibleによるコード化
- アプリケーション監視のためのPrometheus導入
- 横断的なデータ可視化のためにGrafanaを導入
- 脆弱性スキャナVulsの導入
- マイクロサービスアーキテクチャの構築
ひとつずつ簡単に説明していきます。
Terraform, Ansibleによるコード化
まず、課題としてあげたようにブラックボックス化していたサーバー設定をコードに落とし込むことを着手しました。
インフラリソースはほぼ全てAWSを使用していたので、CloudFormationも案として挙がりましたが
という理由でTerraform一択になりました。
※ ちなみに、今はCloudFormationで変更検知できるようになってます。
terraform importと合わせてTerraformingも使用しました。
Terraformのベストプラクティスがはっきりせず、tfstateの分け方など苦労しましたがなんとか5営業日ぐらいかけてコード化しました。*1
並行して、既存リソースをAnsible化することを業務委託の方にやっていただきました*2
結果
- これまで全て外注で行っていたネットワーク・サーバ構築を社内で行なえるようになった。
- このAnsibleコードをローカル環境でも使うことで高い再現性と冪等性が保たれます
アプリケーション監視のためのPrometheus導入
そもそも社内に監視ツールがなかったので導入することになり
Sensu（Push型）かPrometheus（Pull型）で迷いましたが
SRE本で紹介されてたり、使ってみたいって思いが強かったのでPrometheusを採用しました。
Push型とPull型の違いなどはこちらの記事がとてもわかりやすかったです。
結果
- まだそんなに深く使ってないから正直よくわからない
- PrometheusのGUIは多くのことができないから結局可視化のためにはGrafanaが必要
- 効果的なアラートを出すためには根気と時間が必要
- アプリケーションの仕様に精通している人の協力が不可欠
横断的なデータ可視化のためにGrafanaを導入
システム構成はいたってシンプルなのですが、障害発生時にどこに問題が起きているのかわかりづらいという課題がありました。
Prometheusの可視化のためにGrafanaを検討したのが始まりですが
AWSのCloudWatchもデータソースとして使用できるため
約10個ほどあるAWSアカウントのデータを一元化できるのは予想以上のメリットでした。
結果
- BIツールとして使うには難しい
- 標準のままでも一元化して見れるのでメリットが大きい
- 未知の障害が発生する度にダッシュボードを作って関連リソースを見えるようにしておくとか
- Grafana自体でアラートを発砲できるのでちょっとした監視ツールにもなる
脆弱性スキャナVulsの導入
結論からいうと途中で断念しました。
Vulsが動くコンテナを作り、ECSのタスクとして起動して実行しましたが ECS最適化インスタンスにyum-utilsが入ってないとかでローカルホストのスキャンができねぇ！
yum-utils普通にいれるのもシャクなので しょうがないから普通にCentOSのインスタンスにインストール
できた！感動した！VulsRepoも非常に見やすい！
構築にあたり新卒時代の同期であるVulsコントリビューターあだちんのブログを参考にさせてもらいました。
【脆弱性スキャナ】Vulsをインストールしてみた！ – ADACHIN SERVER LABO😎
結果
- あれ、私のサーバの脆弱性多すぎ！？
- この辺の面倒見切れるチーム体制ではありませんでした（時期尚早）
マイクロサービスアーキテクチャの構築
マイクロサービスに関しては機会があれば別の記事でまとめようと思います。
前述のシステム図でいうAPIをコンテナアプリケーションとして設計・構築しました。
非常に見づらい図で申し訳ありませんがこんな感じ
結果
- 全てをマイクロサービス化するのはしんどいし正しいことではない
- X-Rayのトレースに感動した
- Fargateは銀の弾丸ではなかった（言いたいだけ。でも思うところはある）
- サービスが増えるとEnvoyやKongといったサービスメッシュが必要になると思います
まとめ
最大の成果は、念願のインフラエンジニアを雇うことができたこと
やっぱり楽しそうなことをやっている場所にエンジニアが来てくれるんだなと
インフラ出身の人からするとSREはもともとやってたことに名称がついたに過ぎないというけれど
どんどんインフラの仕事がアプリケーションレイヤーに寄っていっているような気がする。
他社のSREの募集要項とか見るとやたらレベル高そうだけど
そんなロックスターの採用が難しいなら、ソフトウェアエンジニアをSREチームに迎えるのもありなのでは？と思いました。
