はじめに
この記事は リクルートライフスタイルアドベントカレンダー2018 の17日目です。
ホットペッパービューティーでエンジニアをしています。shaseです。
現在開発中のプロジェクトが、大人の事情によりハイブリッドクラウド構成になっているので、開発をしている中で思ったことをつらつら書いてみたいと思います。（ネットワークエンジニア視点ではなく、開発者視点です。）
プロジェクトでの自分の役割はプロジェクトマネジメント業が主になってしまったので、今回使っているテクノロジの詳細は、誰かが会社のブログに書いてくれると信じて概ね端折ります。
今回はAWS前提の話になります。
TL;DL
- 特別な事情がない限りハイブリッドクラウドはやめましょう。
- 専用線(DX)を使わないことも検討しましょう。
- 現在普及しているテクノロジを用いればそれなりにアジリティの高いオンプレミス（ただし運用コストは支払う必要がある）環境が用意できるはずです。オンプレミスに寄せるか、クラウドに寄せることができないか考えましょう。
構成概要
- 今回は、モノリシックなAPIのリプレイスプロジェクトです。ざっくり下記のようなものをつくっています。
- BackendAPIがオンプレミス側にあり、アグリゲーションするBFFがAWS側にあります。APIの通信はHTTPSです。（BFF/BackendはL7で連携しています。）
- AWS側の会社共通部分を管理するチーム、オンプレ側の共通部分を管理するチームが、自分たち開発チームとは別に存在しています。
ハイブリッドクラウドにするときのコツ
専用線(DX)は使わない、もしくは使ったとしてもアドレッシングやNATには注意
専用線を使わない構成をまず考えましょう。使う場合でも、仕組み上パフォーマンス的にLAN内と同じようなクオリティは期待できない（期待してはいけない）ので、ステートフルなプロトコル(JDBC等）を使う際は特に注意です。
また、専用線を使った場合、ネットワークがオンプレミス側に引きずられます。（IPアドレスの設計等）。クラウド側のメリットを殺す結果にしかならないので、可能であれば専用線を使わない構成を検討しましょう。
オンプレミス側のアドレスが潤沢な場合（あまり経験がないですが...）は、アドレッシングも容易ですが、そうでない場合はNATを使わざる得ないケースも多いかと思います。
仮にNATを使った場合でも、オンプレミス->クラウドの通信がなく、クラウド->オンプレミスだけの通信であれば、クラウドN対オンプレミス1のNATにし、クラウド側のIPアドレス体系の柔軟性を確保するようにしましょう。（オンプレミス->クラウド側の通信は非private通信を検討しましょう）。
今回のプロジェクトでは、当初ネットワークレイテンシを気にして、専用線(DX)を使う構成を準備していました。が、性能試験の結果、使わなくても今回のユースケースであれば問題のない範囲に落ち着きそうということで、使わない方向で最終調整しています。
オンプレミス側/クラウド側で揃えられる部分を揃える
ただでさえ複雑な複雑になりがちなので、なるべく扱う人間のコンテキストスイッチを小さくする努力はしました。
- AWS側でAmazonLinuxを使い、オンプレ側でCentOSを使うように（近いディストリビューションを使う）。
- システムのモニタリングはAWS側/オンプレ側どちらもDatadogで統一。
- ログの取扱は、ホットペッパービューティーのログ集約している外部システムにオンプレミス/クラウド共に集約。
- 分散トレーシングはAWS X-Rayで統一。
などなど
ハイブリッドクラウドのいいところ
部分的にでもクラウドの恩恵が受けることができる
部分的とはいえ、クラウドを使うことができるようになった恩恵はかなり大きいものでした。この1点をもって、部分的にでもプロジェクトでAWSを使ってよかったなと感じています。
- 開発チームが環境などを自由にすぐつくれる。
- CodeBuildなどの開発支援ツールがすぐつかえる。（開発環境コンテナをECRで管理できる等々）
- 全部オンプレミス側で用意するより圧倒的に下がるコスト。
などなど
ハイブリッドクラウドのだめなところ
リリース方式を統一するのが難しい
例えばCodeDeployにはオンプレミス版もあるので、CodeDeployでクラウド側/オンプレミス側のデプロイ方式を統一させることができるのでは、と事前に考えて検証してみたのですが、現実的にそれは難しいと考えました。
- CodeDeployのオンプレミス版ではIAMの管理が非常に煩雑になってしまう。
- リリース作業というのは、それに付随するオペレーション（ロードバランサー配下のものをinactiveにしたり等）が発生するが、それらすべてをCodeDeployのオンプレミス版でコントロールするのは非現実的だった。（AWS側はリソースのコントロールがすべてAPI化されているので大丈夫）。
クラウド側/オンプレミス側それぞれでリリース方式は考えたほうがいいと思います。
障害ポイントが増える
単純に障害ポイントが増えます。問題の切り分けも、オンプレミス側の知識とクラウド側の知識が要求されるので、難易度が上がります。
オンプレミス側のスケーリングが難しい
今回の構成でいうと、Backendのスケーリングが難しいです（あたりまえ）。バックエンドのスケーリングが難しいということは、BFF側だけオートスケーリングするような構成にしてもしょうがないということです。クラウド側の恩恵は部分的なものにならざるを得ません。クラウド側だけ攻めた構成というのも難しいです。
おわりに
ネガティブなことも書きましたが、アジリティの低いオンプレミスしか使えないような環境であれば、ハイブリッドクラウドも十分検討に値すると思います。
ただ、いろいろ注意するべき点は多いので、PoCなどを通して、落とし穴を回避するのは大事だと思いました。
それでは、めりーくりすます！