サービス変遷期におけるTPM兼任SREの役割、サービスレベル維持しつつトイル削減して価値向上に集中できる環境づくり by 飯伏政樹

「サービス変遷期におけるTPM兼任SREの役割、サービスレベル維持しつつトイル削減して価値向上に集中できる環境づくり」

■ 発表カテゴリ

・Practices: SREの実践例と得られた教訓
・Case Studies: 実際の導入事例や失敗談

■ 発表概要（400字程度）

転職してきて最初に配属された「建設業向けコミュニケーションツール・現場クラウドConne」の開発チーム。
ベータ版として数十ユーザー向けにサービスを運用していた時期から5万ユーザーまで伸長してきた現在に至るまで、インフラ構成に少しずつ手を入れながら変化してきました。。

小さくはじめて少しずつ育ててきた実践例を通して、それぞれの課題に通してどのように向き合って。
サービスレベルを維持しながら、開発者スピードを妨げず、に変更を加えてきたのか。
また、TPM兼任ということでDevと密に連携を取りながら、時には自身もDevとして機能開発しながらSREの役割として信頼性の確保とサービスの加速、増え続けるトイルの削減といかに向かい合ってきたか。

事例や教訓を共有したいとおもいます。

■ 発表の詳細（1000字程度）

私たちが開発・運用する建設業向けコミュニケーションツール「現場クラウドConne」は、その成長の過程で幾度となくアーキテクチャの変遷と運用の課題に直面してきました。
当初Webアプリエンジニアとして参画し、テクニカルプロダクトマネージャーへ役割が加わり、元インフラエンジニアとしての経験を活かしながら未経験SREとしても関わっていくというチャレンジの連続にあふれていました。

ベータ~サービス開始期: EC2オールインワンとあふれるアラート

サービス開始当初(2018年頃)は、EC2ワンボックスのオールインワン構成というシンプルな状態でした。
自社を含む数社の限られたユーザーの利用に限られていたため必要十分な構成とも言えましたが。
初期システムにありがちな話ですが、開発と運用を兼任する中で、頻発するエラーログやメトリクスのスパイクにあたふたする日々でした。
無差別なノイズは監視疲れを招き、開発のための時間や集中力を削っていくため、重要度に応じて緊急のものはアラームを発し、そうでないものはまとめてレポート形式で確認するよう変更、そもそもinfoレベルやdebugレベルのものはログレベルを是正していきました。

この頃はまだSREという言葉に馴染みがなく、DevOpsという文脈から監視のあり方を考えているような状態でした。

サービス立ち上がり期: ファイルI/Oの改善

徐々にユーザー企業が増えていき、建設業独特とも言える利用形態、現場に行く前、帰った後の時間帯、雨の日にファイルのアップロード、ダウンロードが集中するといった事態に出くわすことが増えてきました。

まずはファイルを一時保管していたmongodb/GridFSがリバースプロキシやアプリケーションとリソースを食い合う状況を、インフラを使いこなすのではなくサービスとして使い倒すという考え方からDocumentDBへ移行していきました。
また、同様にクラウドリソースの活用と、セキュリティと開発運用コストのバランスを取りながら、S3に保管しているファイルの多くを署名付きURLをかつようすることで、ファイルI/OやネットワークI/Oをアプリケーションから分離していきました。

SREという考え方、方法論を徐々に取り込み始めたフェーズです。

サービス成長期: からみあったアプリケーションをほどいていく

当初メッセージサービス、ドライブサービスから始まった現場クラウドConneでしたが。
徐々に(建設現場)案件管理、スケジュール管理、ワークフロー機能、ダイレクトチャットサービスなどアプリケーションが増えていきました。
アクセス時間帯特性もですし、アプリ同士のリソース競合、デプロイ複雑化による属人化などの課題が出てきました。
これに対してはリソースの分散のためにEC2インスタンスを複数用意して分離、さらにBlue/Green構成とすることで安全性も高めました。

このとき一足飛びにイミュータブルにしたり、コンテナやサーバレス化を推し進めなかったのは、どんどん増えていくアプリケーション・機能に開発メンバーのキャッチアップが大変になってきたことも考慮してバランスを取ったからでした。

まとめ

これらの経緯や取り組みをあげて、課題に対してとった方法や考え方をあげています。
まだSREのいないプロダクト、所々の事情から工数が限られるSRE、小さなプロダクトを育てていこうとしている方の一助になればと思います。

■ 対象聴衆とその人たちが得られるもの

• まだSREのいない小さなサービスに携わっている人、これから携わりたい人には手始めに出来ることの例をいくつか示すことができると思います
• エンジニア、マネージャーなど何らかの職務を兼ねながらSREを務めている人など、手数が限られている場合の手がかりになればと思います
• 建設業などの比較的ニッチな領域のプロダクトに関心のある人に小さなプロダクトにもSREの手法、考え方が有効だと知ってほしいです

■ なぜこのトピックについて話したいのか（モチベーション）

サーバー運用やネットワークインフラの経験はあったものの、SaaS運用は実質初めてだったので、最初は途方に暮れていました。
事例は大規模なものも多く、DevOpsやSREも最初は規模感が違いすぎて、では実際にはどうすればいいの、と思うことも多かったです。
小規模事例で徐々にサービスの成長に合わせてインフラも育てていくようなSREとしての取り組みを同じような状況におかれた方々と共有したいです。