こんにちは！バクラク事業部DevOpsチームです。
この記事は LayerXテックアドカレ2023 の37日目の記事です、前回はid:kikuchyさんが『歳末！バクラク申請・経費精算モバイルアプリ のびしろ大放出祭 』という記事を書いてくれました。また、38日目はid:suguruが『バクラク Enabling Team の課題とのびしろ #のびしろウィーク』を書いてくださいました！
今回はのびしろウィークということで、バクラクのDevOpsチームの伸びしろをお伝えできればと思います！
のびしろウィークとは
のびしろウィークとは、LayerXの各チームメンバーが自分たちのチームの「のびしろ」について対外的に発信する期間です！ 過去の対外的な発信では社内でうまく行った事例などについては各種発信していましたが、どういう課題があってどういった方の協力を求めているかについての発信はあまり行なっていませんでした。
もちろん多くの企業と同じように不確実な市場で事業に向き合っているため、うまくいったこともあれば、これからもっと整備したい部分、いわば「のびしろ」もたくさんあります。 今回はDevOpsチームが抱えるのびしろについてご紹介させてもらえればと思います！
のびしろをざっと読んでみて、「その課題、一緒に取り組んでみたい！」とすこしでも思っていただけたら、ぜひ気軽にご連絡ください！
バクラクのDevOpsチームについて
正式には「バクラク事業部Platform Engineering部DevOpsグループ」と言います（以下、「DevOpsチーム」と呼びます）。バクラクの各プロダクト群を開発する「バクラク事業部プロダクト開発部」（以下、「プロダクト開発チーム」と呼びます）に対して、プラットフォーム領域からプロダクト開発を支援する横断組織として「バクラク事業部Platform Engineering部」が存在しています。
DevOpsチームはその中でも、インフラ・CI/CD・セキュリティといった領域のプラットフォーム機能を開発・運用するチームです。ミッションとして「プロダクト提供における、プロダクト開発以外の複雑性に対して、必要な抽象化を行い、プロダクト開発チームがプロダクトの価値を最速で最大化できる状態を作る」という言葉を掲げています。バクラクのお客様にとっては直接的に価値を感じられる領域ではありませんが、プロダクト開発チームに対してプロダクトの価値提供を最速・最大化できるプラットフォームを提供することで、お客様への価値提供を最速・最大化できると考えています。
現在、DevOpsチームには4人のメンバーがいます。DevOpsチームの取り扱う技術領域は広く、それぞれのメンバーに得意・不得意な領域があるため、お互いに領域を補完しあいながら、日々プラットフォームづくりに励んています。
DevOpsチームの「のびしろ」
これまでの活動を振り返りつつ、改善すべきポイントや新たに取り組みたい課題をリストアップしてみました。以下にその一部を紹介します。
プロダクトの継続的なデリバリー
バクラク事業部では、『ecspressoを活用したECSデプロイの改善』で紹介されているように、インターフェースを細かく切ったconnect-goのサービスを定義して実装し、ECS Serviceとしてデプロイする基盤 (layerone) があります。最も新しいプロダクトであるバクラク請求書発行は、全面的にlayerone上に構築しています。
紹介した記事中で述べている通り、サービス数は単調に増加していく傾向があります。現時点ではすべてのプロダクトは同じ定期リリースサイクルであることから、定期的に50+のサービスが一斉にデプロイ対象となります。共通パッケージの依存関係チェックを厳密に行えておらず、共通パッケージが変更された場合はほぼすべてのサービスが一斉にデプロイされることになります。この状況では以下のような課題があります。
弱いオーナーシップ
これまでlayerone上に実装された多くのサービスは、それ自体がプロダクトを強く構成するサービスではなく、またプロダクト間を繋ぐ機能や共通利用されるサービスであることから、オーナーシップが相対的に弱い状態になっています。layeroneの仕組みに詳しいDevOpsなどプラットフォーム側のチームがデプロイ開始のトリガーを行い、サービスのデプロイまで行っています。プラットフォームチームはデプロイするサービスの中身をすべて熟知しているわけではないため、適切なオーナーに移譲していく必要があると考えています。
デプロイ順序の弱い解決
サービス間には当然ながら依存関係があります。サービス間通信に利用するパッケージ依存をチェックすることで、ある程度機械的に解決していますが、layerone外のサービスを含め完全な解決ができていません。定期リリース時はドキュメントに変則的なデプロイ手順が書かれることもあり、最終的には人間がデプロイ順序を解決しており、リリースにかける負担が大きいことが問題です。
また、フロー効率を重視することから、一人の実装者が破壊的変更を含む変更を複数のサービスに適用し、定期リリースで一気にデリバリーすることもあります。これはマイクロサービスの前提である独立デプロイを諦めていることになります。現時点での開発リソースや開発スタイルでは最適かもしれませんが、今後さらに開発者が増えたり関心事が増えると難しくなるのではという懸念があります。
CIが詰まったり不安定になる
layeroneではデプロイのためのコードをGitHubでホストし、変更によりGitHub Actionsを動かしデプロイするCIOpsを行っています。具体的には、Dockerイメージをビルドした後、ecspressoの設定上のイメージタグを書き換えるPull Requestを作成し、これをマージするとpush eventによりecspresso deployを行うWorkflowが走ります。これらのActionsは疎結合に構成されており、それぞれのサービスに対して専用のものがあります。
それなりのサービス数を一斉にビルド・デプロイしようとするとGitHub ActionsやGitHub APIが悲鳴を上げることがしばしばあります。起動させたWorkflow Runがunknown eventでstartup failureになったり、Secondary Rate LimitによりAPIコールが失敗したり、push eventで起動するはずのWorkflowが起動しなかったりします。現時点ではすべてGitHub Hosted Runnerを利用していますが、特に最後に挙げた問題はgithub.comのコントロールプレーン側の都合でありSelf Hosted Runnerに変えたとしても解決しないのではないかと思っています（まだ実際に検証できていません）。デプロイPRの作成やデプロイを今よりゆっくり行えば安定性の問題は回避しやすくなる一方、全体のデプロイのリードタイムは伸びてしまいます。
最近の施策
以上の課題に対して、まだ道半ばですが以下の取り組みを行っています。
独立したデプロイ
独立デプロイを目指すWorking Groupを立ち上げました。次のような活動をしています。
- 破壊的となる変更の整理とドキュメンテーション、CIによる破壊的変更の検知
- layeroneで構成されたプロダクトを対象に、ステージング環境で独立デプロイの試行
バクラク請求書発行を対象とした独立デプロイの試行では、依存するバクラク共通管理の変更がまだリリースされていなかったことが原因で、一部機能が使えなくなる発見がありました。バクラク共通管理は最も他サービスへの依存が少ないプロダクトであるため、バクラク共通管理を独立してデプロイできるようにすること次のゴールとしています。
オーナーシップの意識
monorepoでCODEOWNERを設定してCODEOWNERのapproveを必須としたり、プロダクトをまたぐ機能を開発運用するチームを明確化してデプロイを移譲する取り組みを現在進行系で行っています。
開発体験への投資
layeroneにおいては、特にEnablingチームやDevOpsチームが基盤を構築するにあたり実装や意思決定をDesign DocsやADRなどのドキュメントとして残すようにしています。しかしドキュメント間の関連やオンボーディングの観点では改善の余地があると考えてます。また、前述した通りサービスが増え続けると、サービス自体やサービス間の関連を理解する助けが必要になります。バクラクのプロダクトでは全面的にDatadogを採用しており、Service Mapなど組み込みの機能が役立つこともありますが、この領域にはまだあまり投資できていません。依存関係だけでなく、ドキュメント、コード・インフラリソースへ一発で辿れたり、CIやモニタリングダッシュボードと紐付けたりすることで、開発者にとってもプラットフォームチームにとっても便利なポータルを育てていきたいと思っています。最近よく聞くInternal Developer Portalに準じるものです。個人的な興味でBackstageを社内クラスタにデプロイして遊んでみたりしています。可能性は感じるものの、使いたいプラグインがmonorepoを想定していなかったり、ECSのプラグインが無かったりとまだ実用段階にはできていません。
プロダクト開発チームによるインフラ変更のスループット向上とガードレール整備
バクラクではインフラの構成管理にTerraformを使用しています。Terraformのリソース定義の多くは自動生成されており、事前定義したアーキテクチャパターンから所望のアーキテクチャを選択することで、必要なインフラを構築できるようになっています。
バクラクにおける標準的なパターンであれば、わずか数行の設定を設定ファイル（Jsonnet）に記述するだけで、本番環境にデプロイ可能なレベルのインフラが監視も含めて構築できます。以下の例は、休日情報を返却するサービスの設定例です。「business」というドメイン領域に含まれる「HolidayService」をconnect-goで構築、オプションでECS Service Connectも有効化する、という設定です。
domain( 'business', baseDomain( [ connectService { name: 'HolidayService' } + decorator.ecs_service_connect, ] ) )
このような数行の設定と、アプリケーションコードを書くだけで本番環境にデプロイできるのは、サービスの開発者にとっては魅力的ではないでしょうか。
しかし、現実はこのようにうまくいくことばかりではありません。この自動生成にも「のびしろ」が眠っています。先ほどの例で + decorator.ecs_service_connect という設定があることに注目してください。この設定はECS Service Connectを有効化する設定です。昨今、バクラクでは様々なアーキテクチャパターンが生まれ始めており、このような追加設定が増え始めています。結果として、設定が冗長になってしまったり、競合するオプションを設定してしまったりと、設定難易度が上がり続けています。この問題を解決するためには、プロダクト開発チームにヒアリングを行い、アーキテクチャパターンの取捨選択とさらなる抽象化が必要となるでしょう。
また、アーキテクチャパターンによる自動生成ではカバーしない特殊構成や実験的構成については、Terraformのコードを直接書いています。リソースごとに推奨値が利用できるようにTerraform Moduleを整備していますが、ガードレールの整備も必要です。具体的には、semgrepのruleの拡充やTrivyによる静的解析による指摘ができるようにするべきだと考えています。
現時点では、プロダクト開発チームだけでインフラ構築が完了するレベルまで、この自動生成システムやドキュメントが成熟していません。そのため、インフラの構築・変更は主にDevOpsチームが行っています。しかし、バクラクの爆速開発を支援するには、プロダクト開発チーム自身がインフラ構築・変更を行えるセルフサービス化が必須だと考えています。
権限委譲しやすい権限管理システムの整備
バクラクでは、SaaSや社内管理画面上のID管理・権限管理にIdPであるMicrosoft Entra ID（旧称: Azure Active Directory）を利用しています。このMicrosoft Entra ID上には、現時点では「アカウントが割り当てられた人」に関する最低限の情報しか格納されていません。この「のびしろ」について、この章ではお話しようと思います。
これまでLayerXは、組織規模が比較的小さく、管理したい権限の種類も多くはなかったため、非常にシンプルな権限管理方法を採用していました。SaaSや社内管理画面の管理者、もしくは管理部署の上長に高い権限を与え、必要な権限を必要な人に随時与えてもらう、といった方法です。そして、バクラクの開発組織における権限管理は主にDevOpsチームが担当していました。
しかし、LayerXは急成長しており、2025年度に「2025年度に500名体制」を目指しています。
組織拡大による権限付与対象の増加や権限種別の増加、及び、複雑な権限付与要件が発生すると仮定した場合、現行の権限管理方法ではすぐに破綻するでしょう。権限管理は、管理者に権限付与を行ってもらうのではなく、権限付与ポリシーをメンテナンスしてもらうように変更する必要があります。そのうえで、権限付与自体は自動化、権限付与ポリシーの変更はガードレール内であれば（定期的に監査するものの）自由に変更が可能という状態を作るべきだと考えています。
そのためには、権限付与ポリシーに利用できる情報をMicrosoft Entra IDに集約して行く必要があります。具体的には、過去・現在・未来における組織図や「SaaS管理者」といった組織図上には現れないロール情報などです。また、その情報が継続的に、かつ、可能な限り迅速に反映される状態を作る必要があります。
この「のびしろ」はCTO室も認識しており、バクラクDevOpsチームと共同で解決していく予定です。
この「のびしろ」をのばした暁には、従業員一人ひとりが必要な権限を最速で与えられ、かつ管理負荷も抑えられ、組織全体の生産性が向上すると期待しています。また、権限の不適切な付与や使用を防ぐことで、セキュリティリスクも低減できるはずです。
おわりに
今回はバクラク事業部DevOpsチームの「のびしろ」についてお話しました。今回お話した「のびしろ」は一部であり、他にもたくさんの「のびしろ」があります。すこしでも気になったら是非カジュアル面談しましょう。カジュアル面談は「LayerXをもっと知ってもらいたい」が目的なので「今は転職するつもり無いんです…」って状態でも大丈夫です！どしどし応募してください！以下のページから「DevOps」と検索するとDevOpsチームのメンバーとカジュアル面談ができます！
また、LayerX Casual Nightというイベントも開催しています。LayerXのメンバーとゆるく組織の話や技術の話ができるイベントです。次回は 2024/01/30 (火) で日本酒をいっぱい飲める会です。
採用関連情報はこちらに集まっているので一度ご覧になられてください！
