こんにちは、SREの @trunkatree です。
今日は請求管理ロボSREチームのここ1年ほどの活動についてご紹介したいと思います。
本ブログを通してSREチームがどんなことを目指して、どんなことを考えて、どんなことに取り組んでいるのかが伝わればいいなと思っています。
請求管理ロボシステムではちょうど1年ほど前に"開発チームで開発運用するモデル"へ移行していく方針を決め、SREチームはそれを念頭に置いて活動を続けています。 まずはそれに至った経緯からお話したいと思います。
- "開発チームが開発運用するモデル"へ移行することになった経緯
- "開発チームが開発運用するモデル"へ移行するにあたり考えたこと
- "開発チームが開発運用するモデル"へ移行するにあたりやっていくこと
- 2021年度やったこと
- 2022年度やっていること
- 今後やっていくこと
- 終わりに
"開発チームが開発運用するモデル"へ移行することになった経緯
請求管理ロボははじめ外注で開発し2014年にローンチされたプロダクトです。最初期はLAMPスタックで作成されサーバー1台で動いているようなシステムでした（LAMP = Linux, Apache, MySQL, PHP）。 2017年には外注から内製へ移行、コンテナ化、AWS移行が行われ、現在の状況にグッと近くなりました。この内製化をするにあたって、アプリケーションに強い人やインフラに強い人がメンバーに加わり、社内のメンバーが増強されました。
このような背景もあって最初からシステム全体について把握している人は少なく、担当領域がアプリとインフラで分かれているような状況が生まれたと推察しています。
それからプロダクトは順調に成長し、サブシステムの数も増え、組織の規模も拡大して開発チーム数も増えましたが、その分SREチームが開発のボトルネックになりつつありました。上述の経緯から請求管理ロボSREチームはインフラ担当の側面が強いチームでしたので、システム運用やインフラ構築などに多くの時間を使っており、SREingもしたいと思いつつなかなか進められない状況が続いていました。
また開発チームがプロダクトと直接は縁遠い領域の課題で右往左往しているような状況もたびたび見られ、SREチーム（というか私）としては「もっと環境整備できていれば、開発チームがそんなところで立ち止まって悩む必要なんてないのに…」という歯痒い気持ちが強くありました。
"開発チームが開発運用するモデル"へ移行するにあたり考えたこと
上述の課題を解決するにあたり、SREチームの人員を増強して解決するという方法もあるかと思いますが、昨今の採用難易度やスケールする組織づくりのことを考えると"開発チームで開発運用するモデル"へ移行していくことが妥当な判断に思われました。つまりこれまでSREチームで担当してきた業務を開発チームに移譲し、SREチームはもっと開発を下支えするような環境整備やSREingの推進に時間を使っていく方針です。
2021年に請求管理ロボシステムEMと相談し、この方針を取ることとなりました。これにより、仕事に取り組む際に意識することで多少変わる部分もあるかと思うので、いったん重要なポイントを整理します。
- スケールする組織をつくる
- SREチームが開発のボトルネックにならない体制をつくる
- SREチームが開発チームの規模に比例して大きくならずともまわる体制をつくる
- SREで担当してきた領域を開発チームに移譲していく（システム運用・インフラなど）
- SREチームはその活動を下支えする環境の構築をする（≒ Platform SRE）
- 全開発チームに共通のバックオフィスに近いような領域から優先して改善を進める（全開発チームに影響のあるボトルネックから改善していかないと結局そこでのコミュニケーションコストが足かせになってしまうので）
- 開発チームが運用もうまくやっていくためにはどうすればよいか？を考える
- ナレッジ共有・SREの推進をやっていく（Enabling SRE）
- とはいえ何よりも開発チーム自身が学び成長し続けることが大切と考える
特に3つ目の"開発チームが運用もうまくやっていくためにはどうすればよいか？"というトピックが重要だと思っています。 開発チームのエンジニアとSREチームのエンジニアではスキルセットや経験してきた環境・文化が異なるので、ある日突然「はい、お願いね」というわけにはいきません。 なので、ナレッジの共有やSREプラクティスの浸透を目指したSRE推進活動（Enabling SRE）をやっていきたいと思っていますが、変化し続けるこの世の中でいつもいつもSREが最適解を提供し続けられるとも思っていません。限界があると思っています。 そこで、何よりも大切なのは開発チーム自身が学習し成長し続けられることだと考えています。 言い方はいろいろありそうですが、開発チームが学習サイクルを高速にまわし続けること・PDCAサイクルを高速にまわし続けること・フィードバックループを高速にまわし続けることこそが大事で、SREチームはそれを下支えする環境づくりを担当します。
また開発サイクルが開発チームで閉じていることも重要なファクターだと考えています。コミュニケーションコストの問題が大きな理由ですが、質高くフィードバックを得て着実にナレッジに変えていき、強固なチームをつくっていくという意味でも効果のあることなのではないかと思っています。普段は朝会も含めチームごとに活動しているので、意図せずともそこだけの共通言語やそこでだけ共有されるナレッジが必ずあるはずだと思っており、開発サイクルがその中で完結していることで濃いアクションにつながるのではないかという気がしています。関心事項の分離やオーナーシップの醸成なんかとも関係があるでしょうか。ちょっと未整理です。
さきほど"フィードバックループを高速にまわす"という言い方もしましたが、ここでフィードバックとはユーザーやビジネスチームからの直接的なフィードバックもそうですし、広義に捉えれば、例えばデプロイした結果メトリクスがどのように変化したか？というようなモニタリングから得られる情報なども一種のフィードバックと言えるのではと考えています。必ずしも受動的なものだけでなく、自分が起こしたアクションによってどんな変化が生まれたか？をプロアクティブに得て改善を考えるということです。なのでSREチームではこのようなデータドリブンな行動を促進する仕組みづくり・基盤整備もやりたいことの1つです。
ということで、
- SREプラクティスの浸透、Postmortemなど学習のためのツールの浸透、文化形成
- 開発チームが自由に失敗と学びを繰り返せるような環境の整備・権限の移譲
- とはいえクリティカルな事故は起きないような安心安全な環境の整備・ガードレールの整備
このようなトピックがSREチームの主題となります。
"開発チームが開発運用するモデル"へ移行するにあたりやっていくこと
上記を踏まえて、改めてSREチームがやっていくことです。大きくは以下の2つです。
- 「プロダクト開発チームがプロダクトの開発運用を通して自立的に学び改善し続けられる環境をつくる」
- 「開発者が開発に集中できるようにセキュリティ/コンプライアンス/ガバナンスについてガードレールの敷かれた環境をつくる」
この2つのトピックは攻めと守りの関係にあると捉えられます。1つ目は開発チームの自由度を上げる攻めの施策で、2つ目は会社として守るべきところは守るという守りの施策です。 会社からSREに下されるオーダーとしては2つ目のほうが強いでしょうから、それに終始せずこの2つをうまく両立していくこと、ビジネスアジリティとガバナンスコントロールを両立していく意識が大切です。
開発チームの自由度を上げるという文脈にSREで担当してきた領域を移譲していくという気持ちも込めているのですが、ここでは単に移譲するだけでなく、負担にならないよう整備してから移譲する・セルフサービス化する・そもそも無くすなどの方法が考えられ、なるべく省力化を目指して取り組みます。
2021年度やったこと
ここまで、2021年に"開発チームが開発運用するモデル"へ移行する意思決定をしたと書いてきました。 方針の話ばかりでしたので、ここでは例えば2021年度はどんなことに取り組んだのかをご紹介したいと思います。
Terraformのバージョンアップ、インフラリソースのTerraform化、TerraformのCI整備
Terraformまわりの改善に取り組みました。請求管理ロボはAWS上に構築しており、インフラリソースはTerraformで構成管理しています。 しかし以下のような課題があり、インフラを開発チームに移譲していくにはなかなかハードルの高い状況となっていました（SREで開発運用するにも手間のかかる状況でした）。
- 事情によってTerraformで管理できていないインフラリソースがある
- インフラ開発するにはハイコンテクストな状況になっている
- デプロイ処理が本番環境/テスト環境で環境差異がある
- 認知負荷が高い状況
- すべてのインフラリソースをTerraformで管理するにはまずTerraformをバージョンアップする必要がある
- AWS移行で構築した当時のTerraformのバージョンでほぼ停滞しており、バージョンアップにそれなりの労力が必要だった
- 今後も継続的にTerraformを使っていくための基盤が必要
- 今後もラクに（負担少なく）Terraformをバージョンアップしていける環境を整備したい
ということで、Terraformを v0.11 → v0.12 → v0.13 → v0.14 → v0.15 → v1.0 とバージョンアップし、またterraform-provider-awsも最新までバージョンアップしました。 これによりすべてのインフラリソースをTerraform化することができ、環境差異がなく、シンプルなデプロイ処理を実現することができました。 少なくとも"そこに書いてあることがすべて"という状況を作り出すことができ、認知負荷を大きく軽減することができたと思っています。
さらに、今後も継続的にバージョンアップしていけるよう、Github Actionsを用いたTerraform CIフローの導入も行い、"運用のための運用"を軽減する仕組みを整えることができました。
結果、
- ハイコンテクストで認知負荷が高い状況
- → コードを見て素直に開発すればそれで正しく実装できているようなコードになった。レビュー側も気合を入れる必要がなくなった
- デプロイ処理に環境差異がある状況
- → 環境差異はなくなり、テスト実施時に気を使う必要がなくなった。特別に認知する必要がなくなった
- Terraformをバージョンアップするにもひと手間かかる
- → バージョンアップPRが自動で作成され、それをレビュー&マージしてワンクリックすればapplyされバージョンアップできるようになった
ということで、この取り組みによってインフラ領域を開発チームに移譲していく土台をつくることができたと思います。
デプロイ処理の堅牢化
デプロイ処理にあった課題を解消しました。課題を残したまま開発チームに移譲するにはコミュニケーションコストが高くつきますし、事故の起こり得ない安全な環境をつくる施策とも言えます。 また、上述のTerraformバージョンアップをしたからやっと実施できるようになったという背景もあり、続けて取り組みました。
- これまではデプロイ処理の実行開始だけしてデプロイステップを終了していたので、デプロイ処理に失敗していても気づけなかった
- → デプロイ処理がきちんと完了したことまで見届けてデプロイステップを終了させるようにしたので、失敗すれば認知できるようになった
- これまではDBマイグレーション処理の実行開始だけしてマイグレステップを終了していたので、マイグレ処理に失敗していても気づけなかった
- → マイグレ処理がきちんと完了したことまで見届けてマイグレステップを終了させるようにしたので、失敗すれば認知できるようになった
- 上記の通り、実行開始だけしてステップを終了していたので、フロー上はマイグレ→デプロイの順だが実際にはそうなっていない場合があった
- → マイグレ処理が完了したことを見届けてからデプロイ処理に進むようにし、処理の順番を明確にした
- DBマイグレーションのロールバックをするには手の混んだ手順を実行する必要があった（ほぼSREにしかできなかった）
- → 他の処理と同様にセルフサービス化した
ということで、特別に気をつける必要なく、安心して開発できるフローに近づけることができました。
このように、SREでしか認知できない問題（開発チームで認知しようとするとけっこう負荷がある問題）を解消し、SREからの移譲・民主化の道を進めています。
2022年度やっていること
次に主に今年やっていることを簡単にご紹介します。2021年度は年の途中で方針を決めたこともあり、上記は方針変更がなくても普通にやるようなことでしたが、今年2022年はより戦略的に取り組んでいます。
- SSL証明書のAWS Certificate Manager移行
- AWSマルチアカウント戦略・環境分離
- DevOpsリソースのTerraform化
- JenkinsからCodePipelineへの移行
- DBユーザー管理のTerraform化
- 環境分離・AWSアカウント分離
- 権限設定の再設計
- AWS Organizations の導入・SSOの導入
SSL証明書運用やJenkinsサーバ運用など、SREしかわからないような作業をなくしていく取り組みです。 またAWSマルチアカウント戦略を取り、環境の分離を進めます。これにより権限設定が単純で明確になり、セキュアでガードレールの敷かれた開発環境をつくっていきます。 各環境で共有して使っているリソースを解消し（Jenkinsなど）、コード化されていないリソースのTerraform化を進め、横展開しやすい構成に変えていきます。
2021, 2022年度のタスクの一部をご紹介しましたが、請求管理ロボSREチームは基本的に私一人という状況もあり、これらはSREのプロ集団である 株式会社Topotal さんのお力をお借りしながら進めています。SRE as a Service を大いに活用させていただいており、実際に実装タスクをお願いしたり、相談相手としてアドバイスをいただいたりしています。TopotalさんとのMTGはとても勉強になりますし、一週間で最も楽しい時間の一つです。
今後やっていくこと
前述の通り、まずはAWSアカウントなどバックオフィスに近いような領域から整備していき、それからゆくゆくはプロダクトに近い領域の改善にも手を出していけたらと思っています（開発チームを支援するという立場になるでしょうか）。基本は今回ご紹介した方針に沿ってタスクに取り組んでいるところですが、現在手を付けられているのはまだまだほんの一部という状況です。"プロダクトそのものではないが開発運用を促進する基盤"の整備/開発運用に取り組み、セキュアでガバナンスが効いていてかつ身動きが取りやすく、全社的にデータドリブンな動きができる環境をつくっていきたいです。またこれらと同時に、各開発チームがチーム自身で開発速度と信頼性をコントロールするなど、開発チームが自然とSREingを実践できるような体制をつくっていきたいと思います。
終わりに
今回は請求管理ロボのSREチームが最近はどんなこと考えてどんなことに取り組んでいるのかについてお話しました。 人類にとって未解決問題である"システムをうまく開発運用するにはどうすればよいか？"という難題に一事例として取り組むのはとてもおもしろいです。 各社似たような悩みもあったりしますが、知見を共有し合い、最終的にはそれぞれの状況に合わせたカスタマイズな実践が必要であるという点もおもしろいなと思っています。これからも模索を続けていきたいと思います。
この問題に一緒に向き合い取り組んでくれる仲間を大募集しています！
We are hiring！！
ROBOT PAYMENTでは一緒に働く仲間を募集しています!!!
speakerdeck.com
www.robotpayment.co.jp
🎉twitter採用担当アカウント開設！🎉どんどん情報発信していきます！！
