こんにちは。カミナシのソフトウェアエンジニアisanaです。 「カミナシ レポート」の開発に携わっています。
筆者は昨年の11月にカミナシにjoinしました。これまでプロダクトの開発に関わるなかで「これめっちゃイイ!」と全世界に向けて推したい仕組みにいくつか出会いました。
本稿では筆者が推したい仕組みについて、カミナシのエンジニア組織全体に関係するものと「カミナシ レポート」の開発チームに関連するもの、合わせて5つをご紹介します。
紹介した仕組みはそれぞれについて詳しく解説している記事のリンクも記載しておりますので、紹介した各仕組みについては、詳しく解説している記事のリンクも記載していますので、本稿を読んで「うちでも取り入れたい!」と思われた方は是非参考にしてみてください。
GitHub と AWS の権限管理
どんな仕組みか
カミナシのエンジニア組織ではGitHub および AWSのアカウントをTerraformで管理しています。GitHub アカウントとAWS アカウントを管理しているそれぞれのリポジトリにPRを出してマージされれば、CIが回り、自動的に権限が付与される仕組みです。
推しポイント
筆者はこれまで、以下の2パターンの権限管理運用を経験してきました。
- 入社するとEMが個別に会社のOrganizationに招待するパターン
- 申請フォームからアカウント申請を提出し承認されると権限が払い出されるパターン
1のパターンでは人によってadmin権限が付いていたり付いていなかったり、その理由が不明瞭であるなど、ガバナンスの点で課題があります。
一方で、2のパターンではガバナンスが確保できる反面、コーポレート側の対応コストが大きくスケーラビリティに課題があります。
カミナシのエンジニア組織では TerraformによるIaC + CI/CDによる自動化によってガバナンスとスケーラビリティが両立した権限管理を実現しています。
詳しくは後述するブログにて解説されていますが、設計を工夫することでコスパよく仕組みを構築している点も勉強になりました。
詳しくはこちら
kaminashi-developer.hatenablog.jp
Hamayan
どんな仕組みか
Slack上のワークフローから必要事項をフォームに入力するだけでAWS のテンポラリな書き込み権限を獲得できる仕組みです。
推しポイント
前述の通り、AWSアカウントはGitHub リポジトリ上で管理しています。この時に発行する権限は一律read-only権限となっており、必要に応じてテンポラリな書き込み権限を申請する運用とすることで、定常的な業務にて誤ってリソースを削除してしまう等の事故が発生することを未然に防いでいます。
テンポラリな書き込み権限を申請する際に、いつ誰が何のために権限を申請したのかという証跡を残しつつ、開発体験を損ねない迅速なフローを実現しているのがHamayanという仕組みです。
非常に便利な仕組みであると同時に、ツールの名称とアイコンにカミナシらしいユーモアが効いている点も推したいポイントです。
余談
筆者はHamayanを起動するAppleScriptをRaycastのScript Commandを使って呼び出す工夫をして利用しています。
詳しくはこちら
kaminashi-developer.hatenablog.jp
オンコールローテーション
どんな仕組みか
1週間ごとにローテーションするオンコール担当者が、アドホックに発生する各種対応(システムアラーム、発生中の障害への初動対応、社内別チームからの問い合わせ対応)を行う仕組みです。
推しポイント
オンコール体制は、アドホックに発生する対応業務の担当者を明確にし、不測の事態への対応開始の責任の所在が不明瞭になることを防ぐことができます。
また、担当者がローテーションすることで特定の誰かに運用が依存してしまうことを避けられます。
他方で、不測の事態においてもサービスの安定提供を実現することだけでなく、「不測の事態」以外の平常業務を安定して回すことに高い効果を発揮している点も推しポイントです。
上記に加えて、問い合せや障害対応がないときは不具合の恒久対応や技術負債の返済に時間を使う運用となっています。
この運用を続けることにより、以下の2つがメリットとして得られます。
- アドホックに発生する対応の予測可能性が高まっていく
- 不具合の恒久対応や技術負債の返済に使える時間が増えていく
更に、Dependabot AalertsやAWS Security Hub Ffindingsからの通知をオンコール担当者にエスカレーションする仕組みがあります。
つまり、オンコールローテーションはインシデント対応、セキュリティアラート対応、不具合の恒久対応、技術負債返済など、あらゆる領域に効果を発揮する非常に強力な仕組みとなっているのです。
詳しくはこちら
ここからは筆者が所属する「カミナシ レポート」開発チームで活用している仕組みについて紹介していきます。
DBサーバーへの接続
どんな仕組みか
AWS CLIプロファイルと接続先Databaseを引数に渡してシェルスクリプトを叩けば、手軽にAWS Session ManagerとECS Execを利用したリモートポートフォワーディングを開始できる仕組みです。
推しポイント
これまでの伝統的な運用業務では、DBサーバーへの接続の仕組みとしてpublicサブネットに踏み台サーバーを配置し、秘密鍵を管理したり監査ログを収集したり踏み台サーバーをメンテしたりする現場が多かったと思います。
AWS Session ManagerとECS Execを利用することでこれらの運用から解放開放されるだけでなく、ローカルのGUIクライアントからDB接続することができる点も推しポイントです。
関連資料
クラスメソッドさんの記事ですが、参考になるのでご紹介します。
踏み台サーバーがEC2となっている点がやや異なりますが、やっていることはほとんど一緒です。
Feature Flags
どんな仕組みか
システムを利用するユーザーの属性に応じて、機能のON・OFF(（公開・非公開)）を切り替える仕組みです。
推しポイント
近年、Feature Flagsの活用事例を見かけることが増えてきました。Feature Flagsを利用するにあたり、実装コストをかけて仕組みを内製するか、利用コストをかけてFeature Flags管理ツールを採用するか大きく分けて2つの選択肢があるかと思います。
「カミナシ レポート」ではAWS AppConfigを用いることで非常にコスパ良くFeature Flagsを実現しています。
実装コストと利用コストを抑制しつつ、ソースコードの修正やデプロイを伴わずに機能のON・OFF を切り替えられるという主要なユースケースをカバーできています。
詳しくはこちら
kaminashi-developer.hatenablog.jp
まとめ
カミナシのエンジニア組織全体、および筆者の所属する「カミナシ レポート」の開発チームにて使っている仕組みを紹介しました。
これらの仕組みから、カミナシの技術文化の特徴として、攻め(自動化やスケーラビリティ)と守り(ガバナンスやセキュリティ)を高いレベルで両立しようとしている点が際立って感じられたのではないでしょうか。
それぞれの仕組みについての詳細は記載したリンク先で解説されているので、是非参考にしてみてください。
最後に
カミナシではソフトウェアエンジニアを募集しています。
様々な仕組みが日々生まれている一方で、まだまだ解決したい課題はたくさん残っています。
プロダクト開発の傍ら、生産性の改善や負債の返済にも妥協なく取り組みたい方、是非一緒に働きましょう！
