BASEプロダクトチームブログ

ネットショップ作成サービス「BASE ( https://thebase.in )」、ショッピングアプリ「BASE ( https://thebase.in/sp )」のプロダクトチームによるブログです。

Data Strategy GroupのAPI開発の挫折とその後

f:id:beerbierbear:20181217150247j:plain
BASE Advent Calendar 2018 18日目

BASE Advent Calendar 2018」の18日目の記事です。

devblog.thebase.in

お久しぶりです。BASEビール部部長(& Data Strategy Group)の氏原です。 アドベントカレンダーの季節が来て今年も終わりかと実感しているところです。 年末年始、どこにビール飲みに行くか今から悩んでます。

参考:大晦日もお正月もクラフトビール! 年末年始営業日カレンダー (2018 – 2019) – クラフトビールのお店の予定がわかる

さて、今回はアドベントカレンダーということで機械学習そのもののお話は他のData Strategy Groupのメンバーが書いてくれるでしょうから、 私はちょっとインフラ寄りのお話をさせていただこうかと思います。

以前類似商品APIのお話を書きましたが、 それ以降もData Strategy Groupでは関連ワードAPIとか売上予測APIとかいろんなAPIを作ってきました。 APIはAWS API Gatewayを利用してBASE本体に提供していますが、ある日AWSさんからAPIの構成について貴重なアドバイスをいただきました。 どういう内容でご指摘いただいたか、そしてそれにどう対応したか、対応して良かったことを書こうと思います。

Data Strategy GroupのAWSのインフラ構成

Data Strategy Groupは自分たち専用のAWSアカウントを持っていまして、その内部構成は自由に決められます。 メンバーが各々で開発を好きに進められるように機能ごとにVPCを分けて、自分が担当しているVPC内については好きに作っていいよという構成にしました。

f:id:beerbierbear:20181217150430p:plain:w500
AWS環境のVPC構成

VPC間で通信が必要な場合はVPC Peeringで繋ぎます。

f:id:beerbierbear:20181217150640p:plain:w400
VPC Peering

こうして各機能を疎結合にして、各メンバーが割と好きに開発を進められるようにしてありました。 そして問題のAPI Gatewayですが、これは各VPCから生やすようにしていました。

f:id:beerbierbear:20181217150816p:plain:w400
API Gateway

API Gateway自体はVPCとは繋がっていませんので、API Gatewayに来たリクエストをVPC内のサーバにルーティングするにはVPC Linkを設定する必要がありました。

エラー

ある日新しく作ったVPCにAPI Gatewayを生やすためにVPC Linkを作成しようとするとエラーが起こりました。 どうやらAWSの制限に引っかかったようです。 1アカウント、1リージョンあたりのVPC Linkの数は初期状態では5つに制限されています。

f:id:beerbierbear:20181217151027p:plain:w600
VPC Linkの制限

まだ慌てるような時間ではありません。AWSはそもそも初期状態では結構厳し目に制限かかってますからね。 ちゃんと使い出したらすぐに制限に引っかかって緩和申請出すというのはAWS使ってる方なら経験があるでしょう。 引き上げ可能かに「はい」と書かれているわけですからいつも通り制限緩和を申請しましょう。

f:id:beerbierbear:20181217151149p:plain:w500
どれだよぅ

そのままドンピシャな選択肢が見つかりません。 制限タイプの「API Gateway」とか「API Gateway管理」とか「VPC」とかの中を探したんですが見つかりません。 だんだん嫌な予感がしてきました。

仕方ないので技術サポートに問い合わせました。 結果、

「VPC Linkの項目はない。適当な項目選んで申請理由の説明のところにVPC Link数増やして欲しい旨記述してほしい」

とのこと。

…今まで誰も申請してないんだろうか。 気を取り直してそれで申請しました。その結果がまさかのNG。

「VPC Linkの数は増やすことをあまり想定していない。利用方法について聞かせて欲しい。」

インフラ構成変更

その後AWSの担当の方とのミーティングなどを経て、VPC Linkの数を増やすことは諦めて構成を変更することにしました。

f:id:beerbierbear:20181217151307p:plain:w600
API VPC爆誕

まずAPI提供用のVPCを一つ用意してAPI GatewayとVPC Linkで繋ぎました。 VPC Linkの一方の端はNLBです。で、このNLBから直接各VPCのALBに繋ぎたかったんですが、NLBにそういった設定はできません。なので一旦HAProxyにリクエストを飛ばして、ここで各VPCのALBへ振り分けるようにしました。各VPCのALBはVPC内のマイクロサービスへリクエストをルーティングします。

このような構成にすることでVPC Linkの数は1つあればよいようになりました。 さて、こうしてみると実はこの構成のほうが良かったんじゃないかと思います。 その理由としては

  1. キャッシュをAPI VPC内でやるようにすれば各機能でキャッシュとか考えなくてもAPI VPCで統一的に扱える。
  2. APIの入れ替え、A/Bテスト、障害時の対応などがHAProxyの設定変更で行える。
  3. 複数の機能を統合したAPIの提供をAPI VPC経由で行える。例えば画像系とテキスト系の類似度を両方使った類似商品APIなど。

APIを外部に提供するときに考えなくてはいけないことと、提供する機能を綺麗に分離することができたように思います。

まとめ

実運用されていてかつ試行錯誤させてくれる環境って貴重ですよね。いろんな知見が溜まっていく。実は上で説明した今の構成もさらに改善中で来年頭くらいにはまたちょっと変わっちゃってると思います。Data Strategy Groupの環境はまだまだ手探りで構築中ですが、それがまた楽しいでところでもあります。

ではこのへんで。 明日は id:Toshi_Day1 さんがファイナンス系でなにか書いてくれます。 お楽しみに。