こんにちは、SREチームの千代田です。
今回はくらしのマーケットにおけるSREチームの事例を紹介します。
SREチームについて
みんなのマーケットでは今年、SREチームを新設しました。
背景としてはいくつかありますが、
- Dev VS Opsの対立を避け、高速なサイクルでデプロイを安全に行えるようにしたい
- オペレーションを自動化し、サービスが拡大しても少人数で回せるようにしたい
- 本番環境だけでなく、開発速度向上のために開発環境の改善を進めたい
- 障害対応できるポジションを増やしたい
- もともと一部のエンジニアとCTOが対応するといった形で、チームとしての体制が組まれておらず属人化が発生している
- 情報の共有方法に問題があり、対応したエンジニアしか詳細を知らない
- 誰かが入れたサービスだけど、それを入れた詳しい人がもういない
- 昔誰かがやったことなのにそのときの手順が存在しない
などといったものが主な要因として挙げられます。
具体的なこれらの改善策についてはこの後紹介をします。
設立時の目的として、
上記問題点の解決と、「開発業務を行いつつ、運用の自動化」を置きました。
ですが、半年経った今では既存のマイクロサービスの改善など新たな目的も増えており、今後も変化していく予定です。
事例紹介
監視基盤の強化
監視基盤としてもともとはCloudWatchメトリクスを用いていましたが、
計測出来ない値があるなど機能的に足りていないものを補うために、PrometheusとGrafanaを導入しました。
これにより、サーバメトリクスだけでなく、アプリケーションやミドルウェアのメトリクスも取得ができるようになり、監視対象の幅が広がりました。
また、複数の要因によってエラーが出た際に、エラー箇所の切り分けが容易になりました。
ポストモーテムの導入
障害があった際に、ポストモーテムを書いてGitHubへコミットしたうえで、そのURLをSlackで共有するようにしました。
これにより、以前起こった障害が記録されていくと同時に、
全エンジニアは障害がなぜ起きたのか、どのようにして解決されたのか把握できるようになりました。
さらに、失敗から学ぶことにより再発の防止と検知(アラートを導入するなど)にも役立っています。
開発環境の整備
私が入社した際に経験をしたのですが、開発環境の構築に2日ほど時間がかかりました。
原因としては、ドキュメントがあまり更新されておらず足りない手順が存在した為でした。
その為、思い切ってDockerを導入してローカルの開発ではコンテナを使うようにしました。
なぜDockerを利用することにしたかというと、個々人での設定を極力減らしておきたかったのと、
新しく作成するマイクロサービスがDockerを利用するといった理由です。
結果として、導入に成功し、以前より簡単に開発が行えるようになりました。
権限周りの整備
くらしのマーケットではクラウドプロバイダとしてAWSを主に利用しています。
AWSではIAMと呼ばれるAWS リソースへのアクセスを安全に制御するためのウェブサービス
が提供されています。
こちらのサービスを使う際に、Naming Ruleが特に決まっておらず、作る人によってバラバラになっていたものをルールを決めて統一しました。
また、権限が適切ではないものに関しては、
必要に応じてリソースレベルやアクションに対してのみ許可をするなど、権限の見直しを実施しました。
さらに、エンジニアによって権限が異なった状態であったものをグループ単位に分割・権限を集約するなどして、
エンジニアによって権限が異なるといった状態を防ぐようにしました。
これにより、新しくエンジニアが入った際にグループへと追加するだけでよくなり、すぐさま開発へ参加できるようになりました。
データベースの移行
くらしのマーケットでは、データベースにPostgresを利用しています。
もともとはRDSを利用していましたが、Auroraにするとパフォーマンスが最大で5倍出るとのことでしたので、移行することを決意しました。
その際、バージョンを上げた場合の動作なども合わせて検証し、Postgres9.4 -> 9.6へのバージョンアップも移行と同時に行いました。
これによってパフォーマンスが向上し、さらにはパフォーマンスインサイトが利用できるようになり、クエリの可視化が行えるようになりました。
また、一部参照系クエリを読み込みエンドポイントに逃すことにより、さらなる高速化も行えました。
CDNの導入
静的なコンテンツを配信する上でくらしのマーケットのサーバへのリクエストの負荷を減らす目的として、CDNを導入しました。
さまざまなCDNサービスがありますが、今回はAWSのCloudFrontを利用しました。
これにより、CloudFront Popular Objects Reportを利用し、
BytesFromMissesを用いてファイルサイズが大きいものを容易に判別するといったことが可能になりました。
また、当初の目的であるリクエストの負荷を減らすことにも成功しました。
コンテナでの開発ツール作成
くらしのマーケットではマイクロサービスアーキテクチャを採用しています。
既存のマイクロサービスは特にコンテナを使っていなかったのですが、
新しいマイクロサービスを作る際にコンテナで実行したいといった話があり、実際にコンテナでの開発基盤を構築することにしました。
コンテナの基盤としてはKubernetesの採用を考えたのですが、
学習コストの高さや、運用面での不安をカバーしきれなかった為、AWSのECSを利用することにしました。
ECSを利用する上で、ネックとなったのが、既存のマイクロサービスとの結合部分でした。
くらしのマーケットの開発環境ではブランチ別の開発環境(通称 tako環境)を利用しています。
ブランチ単位にすべてのマイクロサービス/データベース/キャッシュ...etcが存在するのですが、
ECS側とのルーティングをどのように実装するかいろいろと考えた結果、くらしのマーケットに特化したデプロイツールが必要な為開発を行うことにしました。
AWSのALBのホスト名でのルーティング機能を利用することを前提に、
TargetGroupの作成やRuleの追加もマネージされたデプロイツールをPythonで実装しました。
また、既存の開発環境へデプロイする際に利用されるAnsibleからでも実行しやすいようにコンテナでラップして使えるようにしました。
ログ基盤の改善
くらしのマーケットではログ基盤としてELKスタックを利用しています。
しかしながら、構築されてから時間が経っている為、ログの取りこぼしやELKスタックのバージョンが古いといった問題がありました。
そのため、手始めにログ基盤の改善としてELKスタックのアップグレードを行いました。
さらに、取りこぼされていたログを入れるようにtemplateを改善しました。
また、ECSやALBのログをCloudWatch Logsに流していたのですが、
Kibanaで見れたほうが串刺しにしやすく便利であった為、ElasticSearchへ取り込むようにしました。
もともとエラーの確認ぐらいでしか使われていませんでしたが、今回は新たにVisualize等を追加してもっとログを有効活用できるようにしました。
- URLに対してのバックエンドでのリクエスト数をカウントして、上位のURLをPieとして表示
- Producer/Consumerパターンで、Consumerが実行したTask数をLineとして表示
など、さまざまな箇所を改善しました。
結果として、バックエンドでのリクエストが多いものについてはSREチームで改善のissueを作成し、対応するなど以前よりも有効的に活用しています。
現状抱えている課題
現状抱えている課題として次のものが挙げられます。
- 分散トレーシングが整備されていない
- perf/DTrace/SystemTapに詳しい人材が不足している
- 昔書かれたコードで、技術的負債が存在している
おわりに
以上、SREチームの事例としていくつか紹介させていただきました。
事例として参考になればうれしいです。
また、今後もやることがまだまだ山積みになっている認識ですが、少しずつでも改善していければと思っています。
最後までお読みいただき、ありがとうございました。
もし、SREに興味がある、ワタシlinuxチョットデキル、みんまで働いてみたい
といった方がいらっしゃいましたら、ぜひ一度オフィスでお会いしましょう。
次回は、エンジニアののりすけさんの予定です。