「インフラ怖い」が生んだSREの業務負担――freeeはどう改善したか：運用コストを減らす3つのポイントとは（1/2 ページ）

　個人事業主や法人向けにSaaSを開発、提供するfreeeは、本番環境にAmazon Web Services（AWS）の「Amazon Elastic Compute Cloud」（以下、EC2）と「Amazon EC2 Auto Scaling」（以下、EC2 Auto Scaling）を活用していた。だが、提供するサービスの増加やマイクロサービス化などに伴い、SRE（Site Reliability Engineer）に運用管理業務が集中して疲弊。そこで、開発チームにサービスの運用管理業務を任せる形で、SREの業務負荷を減らしていったという。

　2019年6月12〜14日に開かれた「AWS Summit Tokyo 2019」において、freeeでSREを務める足立紘亮氏が講演した内容を要約してお伝えする。

「負のスパイラル」が起きた運用管理の現場

　freeeでは、在籍する100人以上の開発者が、2〜10人ずつのチームに分かれてサービス開発を行っている。規模によっては複数のチームが兼任でサービスを開発することもあるという。

　その全プロダクト（サービス）のインフラを横断的に支えているのが、8人で構成されたSREチームだ。例えば、新規サービスをリリースする際には、SREがネットワークやデプロイ環境を構築したり、クラウドサービスの各種構成管理を整備したり、開発基盤の保守業務を行ったりしている。

freeeにおけるSREの役割（画像左）

　「このような体制だと、リリース直後のサービス運用フェーズで、開発チームの問い合わせがSREに集まりがちだ。例えば、誇張しているかもしれないが、『デプロイに失敗した』『サービスが落ちた』『アクセス数が増加してさばけない』『DBのIOPS（I/O per Second）が高く、サーバが耐えられない。どうにかして』といったようなものだ。サービスを1つ運用する分には問題なく対応できるかもしれないが、複数のサービスをリリースして運用フェーズに進む状況では、SREに依頼されることが増加する。その結果、SREは目先のタスクに追われ、本当にやりたいことができない状況になった」

運用するサービスの増加に伴い、SREに作業依頼や問い合わせが集中

　さらにこの問題を加速させたのがアプリケーションのマイクロサービス化だ。

freee SRE 足立紘亮氏

　アプリケーションのデプロイを容易にし、新しい技術を導入しやすくするため、サービスをマイクロサービスアーキテクチャで構築するケースが出てきた。これにより、アプリケーションを構築するための言語やフレームワークが多様化したり、アプリケーションのデプロイフローが複雑化したり、依存するサービスが増加したりした。結果、さらにSREに対して運用管理が集中し、SREチームが疲弊していったという。

　「インフラ構築のために用意された強い権限はSREだけが持っていた。さらに現状のインフラ構成がどうなっているかまで開発者は認識できていなかったため、『インフラを触るのは怖い』という感覚が起こった。そして、SREにインフラ構成の全てを任せる状況を生み出し、SREチームを疲弊させていった」

Copyright © ITmedia, Inc. All Rights Reserved.