株式会社バンクの導入事例：即時買い取りサービス『CASH』などの人気サービスを Google Kubernetes Engine を駆使して効率的に構築＆運用

洋服やスマートフォン・タブレットなどのガジェット、金券・外貨など、いらなくなった売りたいものをスマートフォンのカメラで撮影し、アップするだけでその場で査定され、即時現金が銀行口座に振り込まれるということで話題となった即時買い取りサービス『CASH』。2017 年 6 月 28 日のサービスインからわずか 16 時間半で総額 3.6 億円ものアイテムが現金化され、予想を大きく越える反応からサービス提供を一時中断したことも記憶に新しいところです。今回は、そんな同社のバックエンドを Google Cloud Platform（GCP）がどのように支えてきたかについて、担当エンジニアの皆さんにお話いただきました。

利用している Google Cloud Platform サービス

写真左から

• エンジニア 大竹 将吾氏
• エンジニア 高橋 拓也氏
• エンジニア 中村 勇介氏

株式会社バンク

GCP はエンジニアを開発だけに集中させてくれるプラットフォーム

「2017 年 2 月にバンクが設立され、『CASH』の開発が始まったのですが、その当時、他のプラットフォームで Kubernetes 対応をうたっているところがなかったのが最大の理由です。Docker 対応ということであれば、他の選択肢もあったのですが、前職でそうしたサービスを導入した際、使いこなせるようになるのに時間がかかってしまいまして（苦笑）。また、Google Kubernetes Engine（GKE）のロード バランサが優秀だということも大きなアドバンテージ。仮想マシンを停止させることなく、処理を継続することのできるライブ マイグレーションも魅力的でした。さらに費用面も非常にリーズナブルで、特に事前予約割引のことを考えなくてよかったのが大きかったです。他のプラットフォームを使っていたときは、定期的にエンジニアが集まって、どれくらい予約しておくかを話し合う必要があったのですが、GCP ではその必要がありません。そうした点も含め、GCP は、開発以外の雑事に時間を取られたくないという思いに応えてくれるプラットフォームだと思います。『CASH』は、私ともう 1 人のエンジニアの 2 人態勢で開発していたので、そうした省力化には本当に助けられました。」（大竹さん）

現在、同社のメイン事業である『CASH』と『TRAVEL Now』を含めた、全サービスが GCP 上で稼働。GKE に API サーバーを構築し、『CASH』のユーザーがアップした商品写真や『TRAVEL Now』のホテル外観写真などは Google Cloud Storage に保存、ほか、データベースに Google Cloud SQL を、ユーザーデータの分析に BigQuery や Firebase、Stackdriver などを活用しています。

近年、多くのサービスで採用の進む GKE。バンクのサービス開発において、もはやなくてはならないものになっているようです。

「未経験者には少しとっつきにくいところがあるのは事実ですが、リソースをすべて YAML で管理するのがデファクト スタンダードな利用法になっているため、自然と "Infrastructure as Code" を守れるようになっている点はとても気に入っています。また、そのリソースのアーキテクチャーが極めて優秀。コンテナが、下からコンテナを管理する Pod、Pod を管理する ReplicaSet、ReplicaSet を管理する Deployment といったようなレイヤー構造になっていて、上のレイヤーは下のレイヤーのリソースのことをまったく意識しなくていいんです。これは、いわゆる OSI 参照モデルにも通じるところがあるのではないでしょうか。」（高橋さん）

「私は、コンテナ ランタイムやネットワーク、ストレージなどが、OCI（Open Container Initiative）、ONI（OpenNet Initiative）といったかたちで規格化されているところを評価しています。ONI で言うと、flannel などを使ってオーバーレイで通信してもいいし、Cisco の提供している仕組みを使ってもいい、そういう自由度の高さが確保されているのはありがたいですね。GKE そのものにも言えることですが、ロックインされることは極力避けたいと考えているので。」（中村さん）

なお、現在、『CASH』と『TRAVEL Now』の開発チームには合わせて約 25 名のエンジニアが所属しており、そのうち、約 10 名がサーバーサイドの開発を担当しています。そのうえで、「全員が Kubernetes を使えるようにするのは、まだあまり現実的ではない」（中村さん）ということで、デプロイメントに関しては、1 つのシェル スクリプトを実行するだけで完了するという仕組みを用意し、開発効率を向上させているそうです。

「GKE を多人数で運用していくための工夫としては、それ以外にも、開発環境のスケールを Helm というコンポーネントを使って、YAML を水平に書き換えるということをやっています。」（高橋さん）

Stackdriver や Cloud Functions などの GCP プロダクトで運用効率を向上

「それによって、たとえば、ユーザーからの問い合わせに素早く対応できるようになったのは大きなメリットです。他のプラットフォームでは、複数のサーバーにログが分散してしまうので、それをどのように集約して、運用するかを考える担当者が必要になりますが、GCP ならそれらをすべてお任せできるので、非常に助かりますね。」（高橋さん）

「そのほか、GCP は通知基盤の効率アップにも貢献しています。以前は、データベースから引いてきた、ある特定のユーザーに通知を送る際は、愚直に 1 件ずつ Firebase の API を叩いており、それが何万件にもなると丸一日かかってしまっていました。そこで現在は、それを Cloud Functions に移行。デバイス トークンを Promise を使用して並列化し、急な大量通知の要望に応えられるようにしています。なお、こちらについては、今後は、GKE 上でサーバーレス コンピューティングを実現する Knative を利用することも検討中です。」（中村さん）

「こうした個別のプロダクトの良さに加え、個人的に私が GCP の大きな売りになっていると考えているのが、プロジェクトという単位で環境を分割できること。ステージング環境とプロダクション環境を簡単に分けられるのは本当に便利です。他のプラットフォームでは見たことのない機能だったので、はじめて知ったときはとても感心しました。また、GCP は Google のアカウントと紐付けられているので、権限管理が楽なのも気に入っています。」（大竹さん）

最後に、バンク開発チームの今後の GCP 活用予定についても聞いてみました。

「今、『TRAVEL Now』への導入を検討しているのは、昨年秋に β 版が公開されたマネージド NAT サービスの Cloud NAT です。『TRAVEL Now』では、サービスの特性上、外部のパートナー企業の API サーバーに接続することがあるのですが、その際、特定の IP アドレスを指定されることがあるんです。現在は、Google Compute Engine 上にプロキシ サーバーを立てて、そこ経由でアクセスしているのですが、そのやり方では、サーバーにトラブルが起きた際に、一切の接続ができなくなってしまうので、Cloud NAT を導入することで解決できないかと考えています。」（大竹さん）

「より円滑なサービス運営のために、プロジェクト間、あるいは GKE クラスタ間でのトラストフルなネットワークを構築したいと考えています。具体的には、共有 VPC を組んで、都度、IP を払い出すような仕組みを検討中です。あと、Istio が GKE のコンポーネントに追加されると聞いたので（Istio on GKE  β 版）、そちらにも期待しています。現在、バンクでは、Blue / Green デプロイメントなど、デプロイの安全性を担保する手法を採り入れているのですが、これを Istio に任せられれば、YAML をもっとシンプルにできますよね。」（高橋さん）

その他の導入事例はこちらをご覧ください。