バイセル Tech Blog

バイセル Tech Blogは株式会社BuySell Technologiesのエンジニア達が知見・発見を共有する技術ブログです。

バイセル Tech Blog

メインシステムのアーキテクチャ紹介 (GCPで、GKEを中心にシステムを構築しました)

テクノロジー開発部の村上です。先日、弊社のメインシステムを外部のものから自社開発したものに切り替えました。弊社の業務特性やエンジニア組織の規模を考えますとなかなか興味深い事例になったのではと思い、技術的内容を順次投稿させて頂ければと思います。初回の今回はまずアーキテクチャについて紹介致します。

背景

弊社のメインビジネスである訪問買取を単純化してフローで表しますと、

  1. お客様から電話を頂き、ヒアリングをする
  2. 弊社社員が訪問買取する日程を、ご希望に合わせて調整する
  3. お客様宅に後日訪問し、品物を査定して買い取らせて頂く

となります。ですのでCRM、予約管理、査定・契約管理などの機能を持ったシステムが必要となります。 そのシステムは上記フローのように現場での使用となりますので、操作性が求められます。 また、宅配買取や業者からの買取など派生系も存在し、それらは今後も増える可能性があります。 これらを鑑みて、自社で開発することとなりました。

アーキテクチャ説明

以下の図のように、GCPで構築しました。
そこで動かしているものの基本構成は

  • Vue.jsとiOSアプリによるフロントエンド
  • Rails・gRPCサーバー(Ruby)によるバックエンド
  • データを保存するためのPostgres

となります。

f:id:nmu0:20200421183902j:plain
アーキテクチャ図

特徴としては、

  1. Kubernetesでマイクロサービス構成に
  2. 常時動かす必要がなく状態を持たないサービスにはFaaSを使う
  3. サービスメッシュでOIDCを用いて認証を担保
  4. アプリ・アーキテクチャ共にCI・CDを実現する

が上げられます。

1. Kubernetesでマイクロサービス構成に

マイクロサービスにしたのは、背景で述べたように様々な業務工程が関与しているので、将来的な開発のしやすさを考慮したからです。ドメイン別と言っても良いかもしれません。サービス間のやり取りが多数発生するので、gRPCで通信しています。

2. 常時動かす必要がなく状態を持たないサービスにはFaaSを使う

Kubernetesを立てているので動かそうと思えばFaaSを使わずに何でも動かせますが、管理コストや初期開発コストは大きいです。また、knative等を使わない限りはゼロまでスケールダウンしません。そこでFaaSを使い、その上でパフォーマンスやライブラリの充実度を考慮してGolangやPythonで実装しました。今回はIP制限を掛けている箇所もあるので、Cloud Run for Anthosが重宝しました。

3. サービスメッシュでOIDCを用いて認証を担保

マイクロサービスなので認証を各サービスに実装したくはなく、かといって認証用サービスを作るのも大げさだと思い、サービスメッシュであるIstioのOIDCによるorigin authentication機能で実現しました。SPAやiOSからAPIを叩くだけでセッションという概念が不要なのも大きかったです。ただ、外部フォームやGoogle App Script上でOIDCによる認証をするのは難しいので、別途Cloud Endpointsを使って認証しています。認証以外では今の所そこまでサービスメッシュを活かしきれていないのですが、各サービスのメトリクス取得にはIstioが役立っています。

4. アプリ・アーキテクチャ共にCI・CDを実現する

CI・CDは今やどの会社も重要視していると思いますが、今回のシステムで主に以下で採用しています。

  1. アプリケーションのlint、テストの実施: Cloud Buildで実施
  2. GCPのアーキテクチャ自体の構築: Terraform Cloudでデプロイ
  3. Dockerイメージのデプロイ: Cloud BuildでGoogle Container Registry (GCR)へデプロイ
  4. Kubernetesへのデプロイ: GCRへのイメージのデプロイをトリガーにSpinnakerでデプロイ
  5. Vue.jsのデプロイ: Cloud BuildでGoogle Cloud Storageに
  6. iOSアプリのデプロイ: CircleCIでAWS S3にデプロイ (Apple Developer Enterprise Programを活用)

SpinnakerだけはGKEに構築し自分たちで運用しないといけないのですが、
開発用やStaging用クラスタへのデプロイにも柔軟に対応出来るので、それだけの価値はありました。

まとめ

アーキテクチャの大枠について説明させて頂きましたがいかがでしたでしょうか。 図で見ると大規模かつ複雑に見えますが、構築はほぼ一人で全て行いました。 Kubernetes以外はアプリケーションさえ用意できれば簡単に構築でき、それを組み合わせていったら出来上がった印象です。 次回以降はより詳細な内容や、技術的に面白い箇所の投稿をしていきたいと思います。