kifutown を支える運用業務と基盤システム
kifutown 業務基盤システムのアーキテクチャと開発プロセス
こんにちは。ARIGATOBANK バックエンドエンジニアの富樫です。社内では主に kifutown のバックエンドAPI と、本記事で紹介する業務基盤システムの開発を担当しています。
この記事では、kifutown を支える運用業務とその基盤システムにフォーカスし、
- システムアーキテクチャと実行基盤、技術スタックとその採用背景
- お客様の大切な情報を守る認証・認可のしくみ
- 開発プロセスにおける運用業務との向き合い方
についてご紹介します。
kifutown の運用業務
はじめに kifutown の運用業務について簡単にご説明します。
kifutown には、日々行われる業務として以下のようなものがあります（あくまで一例です）。
- お客さまからの問い合わせへの対応
- 寄付プロジェクトの審査
- 規約違反者のモニタリング
- 寄付者さまからの入金
- 当選者さまへの振り込み
- お客さまからの規約違反などの報告への対応
これらの業務を滞りなく進めるためには、kifutown 内のデータを、お客さまにご利用いただくモバイルアプリとは別の視点で、横断的に閲覧可能な業務基盤システムの開発が必要でした。
一方で ARIGATOBANK にはエンジニアの数がまだまだ少なく、開発リソースも正直なところ限られています。kifutown は、さまざまな事情により駆け足で開発してきた経緯があり、必然的に業務基盤システムについても必要十分な機能の見極めとスピード感のある開発が求められていました。
（開発の経緯については、エンジニア type さんから過去にインタビューいただいています。『「こっちだって打ち上げ直前」前澤友作肝いりのスタートアップ ARIGATOBANK は何を作ろうとしているのか』もぜひご覧ください！）
アーキテクチャと実行基盤
kifutown の業務基盤システムには、アプリケーション実行基盤として Cloud Run を中心としたインフラストラクチャ構成を採用しています。
CTO 河津が ARIGATOBANK Tech Blog 最初の記事『kifutown の設計とアーキテクチャ』でご紹介したとおり、kifutown はマイクロサービスアーキテクチャを採用しています。また、アプリケーション実行基盤に Google Cloud Platform (以下 GCP) の Kubernetes Engine (以下 GKE) を利用しています。
業務基盤システムのアプリケーション実行基盤としても、当初は GKE を利用するつもりでした。そのほうが既存のマイクロサービス開発で得たノウハウや、CI/CD フローをそのまま適用できて開発効率が良いと考えていたからです。
問題は kifutown が利用する銀行 API との接続において、発信元 IP アドレスの固定が求められる点でした。
GKE クラスタは安全性の観点から限定公開クラスタで作成しているため、Pod から外部インターネットへのアクセスは Cloud NAT を経由しなければなりません。kifutown の場合、ID 基盤である ARIGATO ID や Twitter API へのアクセスが外部インターネット通信にあたります。銀行システムへの発信元 IP を固定するには Cloud NAT に単一の IP アドレスを割り当てる必要がありますが、一方でこれは NAT のスケーラビリティを損ないます。
特に ARIGATO ID との通信は、ローンチ当初は kifutown のアクセスに伴って比例的にトラフィックが増加する設計でした。このため、通信経路上の NAT のスケーラビリティはできる限り確保しておきたいポイントでした。
結果として、業務基盤システムは kifutown のマイクロサービスとは VPC サブネットを分離し、別々の Cloud NAT を利用する構成を選択しました。GKE は、クラスタが単一のサブネットに属するため、この時点で業務基盤システムのアプリケーション実行基盤として利用することが難しくなりました。
代替ソリューションを検討した結果、標準のコンテナを利用してサーバーレスな環境にデプロイできる容易さから Cloud Run を採用しました。
技術スタック
業務基盤システムは、主に 2 つのコンポーネントで構成されています。
1 つは、kifutown の各マイクロサービスの API を呼び出しレスポンスを集約する BFF (Backend For Frontend) スタイルのバックエンド API です。もう 1 つは、バックエンドの集約したレスポンスを受けて表示する Single Page Application フロントエンドです。
バックエンドには Go、Web フロントエンドには TypeScript と React、Chakra UI を採用しています。
業務基盤システムは 1 つの画面で表示したい情報量が多く、必然的にバックエンドとやり取りする API のレスポンスも複雑で大きなオブジェクトになります。こういった状況ではやはり型による恩恵を受けたい、との考えから Web フロントエンドの言語には TypeScript を採用しました。
React の UI コンポーネントライブラリである Chakra UI は、最初からひと通りのコンポーネントが揃っていてとても助かっています。ユーティリティファーストなスタイリングについても、シンプルな UI でフラットに情報を表示する業務基盤システムとの相性の良さを感じています。
フロントエンドの静的リソースは、Go 1.16 から追加された embed パッケージを利用し、ビルドしたリソースのディレクトリをまるごとファイルシステムとして Go のバイナリに埋めこんでいます。
通常、静的リソースの配信は Firebase Hosting や Netlify といったホスティングサービスの利用が一般的です。しかしながら kifutown の業務基盤システムを利用するのは業務にあたるメンバーのみでありトラフィックもある程度限られるため、同一コンテナから配信する方法を採用しました。
バイナリへの埋め込みであるためコンテナ内のディレクトリ構成を意識する必要がなくなり、ファイルパスのミスマッチによる混乱を避けることができます。また、必然的にフロントエンドとバックエンドが同一オリジンになるため CORS を気にせず開発できています。
認証・認可
kifutown では、寄付者さまからの入金や当選者さまへの振り込みをはじめ、さまざまな業務で個人情報を取り扱う必要があります。業務基盤システムは、これらの業務をサポートするために個人情報を画面に表示する必要があります。当然ながら、セキュリティにも十分な配慮が必要です。堅牢な認証認可基盤を備え、かつ権限面ではきめ細かなアクセス制御を実現する必要がありました。
個人情報管理の面では、以前 CCO 山崎の記事『プライバシーの管理・取扱いについて』にもあるとおり、執務室内でも隔離されたエリアで扱うなどセキュリティに十分配慮しています。一方で、ARIGATOBANK では昨今の状況もふまえて全社的にリモートワークを推進しており、業務にあたるメンバーの在宅勤務環境を整備する必要もありました。
これらの要件を満たすため、kifutown の業務基盤には BeyondCorp Enterprise が活用されています。
ここでは業務基盤システムへのセキュアなアクセスの実現に大きな役割を果たす 2 つのサービスの活用についてご紹介します。
まずは Identity-Aware Proxy (Cloud IAP) の導入です。これは Cloud Load Balancing とバックエンドコンポーネント (この場合は Cloud Run) の間に IAM 制御の認証レイヤーを設置するサービスです。Cloud IAP により、アプリケーションに到達するリクエストはすべて IAM で許可された Google アカウントによる認証済みのリクエストであることが保証されます。
さらに、Context Aware Access よるアクセス元端末に基づいたアクセス制御を適用しています。具体的には、業務基盤システムに対するアクセスを許可している Google アカウントは、会社支給の Chromebook 端末からのアクセスでないとログインできないよう制御しています。
Google アカウントと利用端末をあわせた認証により、自宅からでも専用 Chromebook 端末とインターネット環境さえあればセキュアに業務基盤システムへアクセスできる環境を構築しています。
また、Load Balancer や SSO プロキシはすべて GCP を利用することで、VDI や VPN といった構築や運用に時間やコストのかかる構成を避けることができました。フルマネージドであるため、アタックサーフェスも少なくなり、セキュリティリスクも低減できています。
プロダクト開発プロセスにおける運用業務との向き合い方
プロダクトにおいて主役となるのは、やはりモバイルアプリケーションのようなお客さまから直接見える部分だと考えています。
一方で、運用業務はプロダクトの基盤となる部分です。お客さまから見えにくい分、間違いなく実施されて当然と期待される部分でもあります。それゆえ、ミスや事故の発生は期待値の大きなギャップを生み、プロダクトのレピュテーションを大きく毀損する結果に繋がりやすい性質があります。
ARIGATOBANK では、運用業務もプロダクトの一部である、という考えのもと日々のプロダクト開発を進めています。
プロダクトの機能開発における優先順位や実施可否の意思決定の場には運用業務を担うメンバーが同席しています。ここでは、運用業務の効率化など内部向けの機能開発においても、ユーザーの目に見える部分と同じ温度感で意思決定に向けた議論をしています。
機能開発における見積もりや要件定義においても同じです。問合せへの対応に必要な情報へのアクセスが確保できるか、プロダクトの健全性が維持できるかといった観点で業務へのインパクトを確認し、運用フローや業務基盤システムへの対応を見落とさないように注意しています。
エンジニア側からの運用業務へのアプローチとしては、業務基盤システムの機能や UI に過不足がないことに合意を得ながら開発を進めています。
また、運用業務を担うメンバーを中心とした運用設計ディスカッションに開発メンバーも参加しています。運用業務への理解を深めるとともに、システムとしてサポートすべき部分、人の手を介すべき部分について議論を深め、過不足のない機能が提供できるよう心がけています。
今後も業務基盤システムの開発を通して、お客さまとのコミュニケーションの迅速化や、運用事故リスクの低減、さらなる健全化の後押しをしていきたいと考えています。
We are Hiring !
ARIGATOBANK では、今後も「お金で困っている人をゼロにする」ために、さまざまな機能やサービスを創出していきたいと考えています。
今までにない未知のサービスを通して新しい未来を創る、そんなプロダクト開発や、プロダクトを通じたお客さまの成功の後押し、より良い未来を創るための健全なプロダクト運営にともに取り組んでいく仲間を探しています。興味をもっていただけましたら、まずはカジュアルにお話できればと思いますので、お気軽に 採用ページ などからご連絡ください！
