ABEJA Advent Calendar 2021 23日目の記事です。21日目のオフィスDXを支える技術（フロントエンド編）のバックエンド編の記事となります。
はじめに
こんにちは、エンジニアの @toshitanian です。 ABEJAは2021年11月にヒューリック株式会社と資本業務提携を行い、その一環として「Bizflex By HULIC」という賃貸オフィスを支えるBizflexシステムの開発・運営しています。 Bizflexシステムでは、クラウドサービスと連携した共用会議室予約システム、取次対応を効率化するゲスト受付システム、社員の所在地・状況可視化システムなどの機能を提供しています。Bizflex システムは、オフィスDXを推進するためのプロダクトなので、インターネットサービスだけでは無く、オフィスに設置されているWiFiや、ビルのセキュリティシステム等とも連携を行っています。
この記事では、Bizflex システムの全体像について大まかに紹介し、アーキテクチャや開発方法についてご紹介したいと思います。
Bizflex の紹介
Bizflexについては オフィスDXを支える技術（フロントエンド編）の記事で詳しく紹介されているのでぜひ読んでみてください。こちらでは写真で雰囲気だけでも紹介できればと思います。
オフィスの様子
ABEJA が開発するアプリケーション
システム全体像
Bizflexのバックエンドシステムは大まかに以下の機能を提供しています。詳細を書いていくと2021年中に記事をリリースするのは難しそうなので、詳細は割愛しつつ各機能をご紹介したいと思います。
SSOログイン
Bizflexのアプリケーションでは会議室の予約やWiFi接続情報の発行などを行なうので、各従業員にアカウントを発行する必要があります。利用者側としては独自アカウントじゃなくて、自社のSSOでログインしたいですよね...? 一方で、サービス提供者としてはSAMLやOIDCの実装なんでやりたくない...。という事で、今回は認証基盤としてAuth0を採用し、Google Workspace や Microsoft 365 でのログインを実現しています。詳細は割愛しますが Sansan社の事例 と同様のB2Bマルチテナント方式を利用しています。
クラウドサービスのカレンダー連携
Bizflex麻布十番の1階には、入居テナントのユーザであれば誰でも使える共用会議室があります。予約はアプリからも可能ですが、いつも使っているカレンダーソフトで会議室を指定してミーティングを設定すれば、自動でBizflexの会議を予約できるようになっています。一方で、他のユーザが会議室を抑えている時間帯はカレンダーソフト上で予約できないようにする必要があります。
今回のカレンダー連携は個人に紐づくカレンダーと連携するのではなく、クラウドカレンダーの会議室リソースと連携する必要があるため、Google Workspace や Microsoft 365 のオーガニゼーションレベルの連携をする必要がありました。幸いにも、どちらにもオーガニゼーション単位で会議室のイベント取得などを行なう機能があったのでそれを利用しました。
また、どちらのカレンダーも会議室に予定が作成された際は、Webhook で通知を受け取る必要があります。他の入居テナントのカレンダーへの同期や失敗時のロールバック処理もありますので、非同期処理・例外処理が多く発生するため苦労しているポイントです。
Meraki Cloud 連携
Bizflex麻布十番はセットアップオフィスであり、デスク等のオフィス器具だけでは無くWi-Fi 含めたインターネット環境も完備されています。意図しないWiFiへの接続を防ぐセキュリティ面や、今後フロアを横断したりビルを横断してのWiFi接続をする利便性を考え、WPA2-Enterpriseを利用して個人ごとのWiFi接続情報を提供しています。
Bizflex麻布十番のWiFi設備にはMerakiを全面採用し、Meraki Cloud 経由で接続情報の管理、アクセス履歴の管理をできるようにしています。Bizflexシステム上のユーザアカウントと連携し、Bizflexのアカウントが発行されたときには、WiFiが使える状態となっています。
ビルセキュリティシステム 連携
Bizflex麻布十番では、共用会議室での打ち合わせのためにゲストが来訪した際に、招待メールに添付されたQRコードを受付端末を読み込ませると、セキュリティドアが解錠されて会議室にご案内されます。また、入居テナントの管理者は、カードリーダーの履歴から従業員の入退館記録を管理画面から閲覧する事ができます。
ビルセキュリティシステムとの連携は、我々としては初の試みで不確実性が高く不安な部分でした。実際に議論・調査を進めて行くと、セキュリティシステムはビルのイントラ内だけで利用する事を想定されていたり、システム操作は人手で触る事しか想定されていなかったりと、一筋縄では連携できない事がわかりました。
結果として、クラウド上のネットワークとビルのネットワークを拠点間VPNを張ったり、RPAでシステム操作したりする事でシステム連携を実現できました。ここは、ネットワーク業者様やセキュリティシステム会社さまと密に連携して何とか実現できましたが、これからのオフィスDXを進めていく上でクリアしていかなければならない部分であるという事を再確認できました。
技術スタック
ここまでBizflexバックエンドの概要について見てきましたが、ここからは実際にどういう開発をしているのかをご紹介します。
言語・フレームワーク
APIサーバやシステムエージェントはGo言語で書かれています。APIサーバーはフレームワークにgin、ORMにgormを採用しています。APIサーバのパッケージ構成は リクルート社の事例 を参考にしたレイヤードアーキテクチャを採用しています。レイヤーが多い分冗長だと感じる部分も多いですが、Auth0, Google, Microsoft, GCPサービス, Meraki など infrastructure 層に相当する部分が多様なので、コードベースが大きくなってきた今では有り難みがましています。
また、メール配信部分に Sendgrid を、認証基盤に Auth0 を外部サービスとして使っています。
インフラ
Bizflexバックエンドシステムは GCP 上に構築されています。APIサーバは Cloud Run でホストしています。当初は Cloud Functions にしようとしていたのですが、ルーティング面など機能面で不足を感じる部分があり、Docker + Cloud Run に移行しました。Cloud Run でもインフラ管理に関するストレスは無いので満足しています。
非同期処理は Cloud Tasks + Cloud Scheduler で バックエンドAPIを呼ぶ事で実現しています。APIのタイムアウト等を考慮する必要がありますが、比較的時間のかかる処理でも今の所は特に問題は発生していません。
モニタリングやログ管理は Datadog で行っています。
構成管理
GCPのリソースの管理やAuth0の構成管理は Terraform を使っています。Auth0の構成管理をどうしようか最初は懸念していましたが Terraform のプロバイダーとしてかなりよく出来ていました。
リポジトリ
リポジトリはモノレポにして、バックエンド関係のコードは1つのリポジトリに入れるようにしました。開発メンバーが以前のプロジェクトで、マイクロサービスとそのリポジトリ管理の辛さを味わっていたため、モノレポを前提に開始しました。ルートディレクトリは以下のような構成になっています。
├── README.md ├── apps/ ├── cloudrun-api-proxy/ ├── docs/ ├── misc/ ├── rpa-agent/ └── terraform/
CI/CD
Github Actions を CI/CD環境 として使っています。Pull request が作成されるとCIでリンタやテストが実行され、developブランチにマージされると、GCP上の開発用環境にデプロイされ、アプリや管理画面が最新のAPIを利用できるようになります。QA環境と本番環境へのデプロイも、Githubのイベントを起点に実行されます。
前項で書いたように、バックエンドと構成管理等は1つのリポジトリに入っているので、変更のあったディレクトリだけ検知して、CI/CDが実行されるようになっています。
まとめ
今回は、システムの概要がメインになり、技術的な詳細はご紹介できませんでしたが、いかがでしたでしょうか？ オフィスDXという事でまだまだ改善ができる領域のプロダクトであり、実際にビルを所有しているHulic社と共同で行っていますので、個人的にはとてもやりがいのあるプロダクトだと思っています。まだまだやりたい事はたくさんありますし、コードベースが大きくなり改善活動もやっていきたいと思っています。
そして、Bizflex 開発チームでは一緒にサービスを作ってくれるエンジニアを募集中です！「まずは話を聞いてみたい」という方にカジュアル面談もお待ちしておりますし、事前コーディング・テストの内容も GitHub で公開 (TypeScript / Go) していますので、応募には興味のない方もぜひご覧ください。
