「AWSとGCPを“選択可能”にしておく」LIFULLに学ぶ長生きするインフラ構築術

——さて、ここからは貴社のサービスのインフラ設計の変遷と、クラウドサービスの関係を伺いたいと思います。オンプレからAWSへの移行は2014～2015年頃だとおっしゃっていましたが、当時AWSを移行先に選んだのはなぜだったのでしょうか。

長沢　オンプレからの移行期間は1年ほどです。LIFULLでは、国内では比較的早いタイミングでAWSを利用し始めていました。当時はまだ東京リージョンが開設していない状態でしたが、その後、東京リージョンができAmazon Virtual Private Cloudが同リージョンで利用可能になった時期に移行を考え始めたので「これは大規模な開発でも使えるな」と感じ、移行に踏み切りました。当時、クラウドサービスの中ではAWSが一番早く機能が充実していたと感じています。

——オンプレによるインフラに、どのような課題を感じてAWSへ移行したのでしょうか。

長沢　環境全体が「オンプレに最適化した設計」にしていたんです。比較的新しいものは仮想化していましたが、古いサーバなどでは1台のサーバにいろんなものを詰め込んでいた状態でした。そうして、システムが大きくなっていくにつれて、どんどんモノリシックになってしまっている、というのが課題でした。微細な変更、例えばパラメータを少し変えるだけでも、システムに対する影響範囲がかなり大きくなってしまっていたんです。

——そうなると開発のスピードが落ちてしまうなどデメリットも多くなりそうですね。

長沢　そこも問題でした。また、自社サーバを管理すること自体の大変さもありました。主要サービスであるLIFULL HOME'Sは一年のうち、繁忙期、つまり特定の時期にトラフィックが増加する傾向があります。入学・入社シーズンなど家探し需要が高まる時期にアクセスが増加します。

そうなると、当然インフラにはそのトラフィックに向けた対策をせねばなりません。トラフィックを予測して、そのためにサーバ機器を調達して、セットアップとラッキングをする必要があるのですが、こうした一連の作業が毎年の人的リソースを圧迫してしまうのです。

また、スペックには一定の余裕をもって機器を調達するので、時期によってはサーバのリソースが余剰になってしまう、という面もありました。こうし背景からインフラをクラウドに移行すべきだという流れになっていきました。

——移行にも相当のリソースが必要だと思うのですが、クラウド化に対して否定的な意見はありませんでしたか。

長沢　当時はまだまだクラウドサービスが浸透していなかったので。「どうなるかわからない」「クラウドって大丈夫なの？」という不安の声はありましたね。

CTOの長沢さん。

——どうやって不安を解消していったのでしょうか。

長沢　一気に移行するのではなく、まずは小さいもので検証していくことにしたんです。ちょうどLIFULL HOME'Sのスマートフォンサイトを作り直すタイミングだったので、その裏側をAWSで作りましたね。

そのサイトで繁忙期のトラフィックの増加に耐えられることなどを試していったんです。こういった検証を少しずつ行っていき、周囲からの不安を取り除きつつサービス全体に導入していきました。

ただ、オンプレミスから移行は移行プロジェクトとしてスピードを出すためにまずはLift&Shiftという方針をとっていたので、クラウドネイティブなシステムにはできていませんでした。

——現在はAWS、GCPともにサービスがかなり細かく、広範に渡っています。もし今、オンプレからクラウドサービスに移行するとしたらどちらのサービスを選んでいたでしょうか。

長沢　難しい質問ですね（笑）。今はAWSもGCPも機能が豊富なので、どちらを使っても課題解決はできるでしょう。であれば、求める機能を備えているかは大前提ですが、あとは全体的なコストや使い勝手などを考えて決めるだろうと感じます。

マイクロサービス化し、「影響範囲」を狭めることで得られたメリット

——オンプレからAWSへの移行が完了し、現在はマイクロサービス化に着手されているそうですね。このプロジェクトはいつ頃から始まったのでしょうか。

長沢　実は、オンプレからAWSへ移行している途中で「マイクロサービス化していこう」という観点はありました。多様なクラウドサービスがあり、「導入しているサービスをどうやって切り分けるのか」「サービスごとにアカウントを分割した方がいい」「できるだけ影響範囲を少なくしていこう」という意見があり、マイクロサービス化を実施していくことになったんです。

——現在、どの程度のサービスがマイクロサービス化されているのでしょうか。

長沢　歴史の長いサービスは切り分けるのが難しく、今は新しいサービスから先にマイクロサービス化を進めています。まだ全体の1～2割くらいでしょうか。アプリのAPIや、1コンテンツなどの単位で切り分けているので、粒度もそれほど細かくしていません。

——マイクロサービス化に踏み切った一番の理由は何だったのでしょうか。

長沢　サーバだけでなくコードもモノリシックになっている部分が多く、共通して使っているAPIなどが多くありました。こうした状態を継続して開発を進めてしまうとコード量はどんどん肥大化して複雑化していってしまいます。LIFULLでは複数のサービスを展開しているので、各チームで開発する際の影響範囲を小さくし、チームがきっちりと裁量を持てる環境の方が合理的だと考えたんです。

——実際にマイクロサービス化してみてメリットだと感じた部分はありますか。

長沢　チーム独自で技術的な判断やリリースなどの判断を素早くまわせるようになったのは大きいですね。以前は共通のサーバを使っていたので、影響範囲を意識しながら判断しなくてはいけない、という課題がありましたので。

また、コストの可視化もメリットです。サーバが共通だと、各チームでインフラへのコスト意識がどうしても希薄になってしまいます。「サーバ費用」というコストがきちんと見えていなかったのです。しかし、マイクロサービス化することによって、コストがチーム単位で可視化され、コスト意識が浸透しやすいのです。

——「可視化」は興味深いメリットですね。

長沢　「見えなかったものを見えるようにする」ということは、チームで開発する上で大きな意味があると考えています。

もうひとつ、よりインフラ環境が身近になることで、インフラの知識を持たないエンジニアもインプットしやすい環境になります。エンジニア個々の成長を促進することも、マイクロサービス化のメリットだと感じます。

——開発のしやすさだけでなく、エンジニアの意識を変える上でも意味があるのですね。衛藤さんと菊地さんはアプリケーションエンジニアとして、マイクロサービス化にメリットを感じる部分はありますか。

衛藤　開発のサイクルはやはり早くなった実感があります。チーム単位でなんらかの判断が下しやすく、その分、開発がしやすくなったのは間違いないと思います。

菊地　振り返ると、アプリで必要な情報を取得する際に、古いAPIでは情報が足りず、複数を組み合わせて叩かなければならないという問題がありました。不要な通信が多くて、結果が返ってくるまでの時間も遅いという課題がありました。

しかしマイクロサービス化を実施しある程度分割できたので、アプリで欲しいデータだけをAPIの結果として返せるようになったんです。これが一番のメリットだと感じています。

衛藤　かつてはWebとアプリが共通で使っているAPIが多かったので、ひとつの修正で大きな影響が出てしまうこともありました。アプリのための修正なのに、Web版にも影響してしまう……というリスクもあったんです。

それがマイクロサービス化によって依存関係がほとんどなくなりました。アプリチームの意図のもと開発ができるので、新たなライブラリを試す、というような判断がしやすく、性能アップも図れる。FirebaseやGCPの導入もマイクロサービス化の恩恵のひとつですね。

Androidアプリエンジニアの衛藤さん。

——なるほど。では、GCPが開発上の選択肢として存在しているいま、アプリ開発におけるAWSとGCPの使い分けをどのように考えていらっしゃいますか。

菊地　チームごとに使用技術を判断するので、「社内でどちらのクラウドサービスが多い」とは断言しにくいのですが、個人的にはアプリをメインに開発するならGCPを使い、WebがメインならAWSかなと考えています。

なぜなら、やはりアプリ開発ではFirebaseが非常に優秀だと考えているからです。アプリで必要な機能が簡単に実装できるようになりますから。そして、Firebaseとの連携を考えると、GCPに一日の長があります。

——Firebaseはバックアップ機能がない、など、まだまだブラッシュアップの余地がある印象があるのですが、ソフトウェアに課題を感じることはありますか。

菊地　そういった足りない部分がある機能は、「使わないようにする」という方針で運用しています。もし使いにくい機能があれば、AWSでの実現を模索するか、自分で組み上げるなどしてカバーするようにしています。

——Firebaseの導入にともない、サーバレスな設計にも取り組まれているのでしょうか。

長沢　サーバレスな設計は増えていますね。開発を始めるときには、サーバレスも含めて、「管理すべきもの」を少なくできるようにする、という前提で考えているメンバーが多いです。

「使い分ける」のではなく、「両方を使える」ことが継続性を生み出す

——さて、少々厄介な質問かもしれませんが、もし新規でなんらかのサービスのアーキテクチャを作るとしたら、「ここはAWS」「ここはGCP」のような使い分けを検討しますか。

長沢　また、先ほどと同じように本当に難しい質問ですね（笑）。例えば今はLIFULLの基盤はAWSになっていますが、もしいちから設計するとしたら、GCPになることももちろん考えられますね。

AWSにももちろんメリットはあります。多くのサービスでの導入実績や、それに基づくサンプルの数はAWSの大きな魅力です。実際に設計する以前に、安心感や安定感に長けたサービスだと感じています。AWSとGCP、どちらを選ぶかと問われると、やはりケースバイケースとしか答えられません（笑）。

——「機能にほとんど差がなくなってきている」と先ほど教えてくださいましたからね（笑）。やはりどちらを選ぶかは開発者次第なのですね。

長沢　そうですね。そうなってくるとAWSとGCPの「使い分け」には大きな意味がなくなってくると思います。つまり、「両方使えるようにしておく」ことが望ましい。

クラウドサービスだけでなく、プログラミング言語やミドルウェアなども含めて、技術の進化のスピードはどんどん早くなってきています。果たしてどの技術がディファクトになるか、誰にも予想できません。

クラウドサービスに限定して考えると、AWSとGCP両方を使っていき、「必要に応じて選択できるようにしておくべき」だと思っています。

——なるほど。確かにリスクを回避する、あるいは、より発展的な選択をするための手段を用意しておくことは大事ですね。そういった「交換のしやすさ」のようなものは以前から意識されていたのでしょうか。

長沢　そもそも、オンプレからAWSへの移行もその一つですね。Amazon EC2であれば物理サーバとは異なり、コピーすることも削除することも簡単で、サーバの交換や切り替えが容易です。

マイクロサービス化も同じです。サービスを細かく切り分けることによって、一部分だけ交換する、といった措置を行えるようになっています。

——最後にそれぞれお聞きしたいのですが、今後クラウドサービスを活用して実現したいことを教えてください。

衛藤　アプリ開発で、もっとGCPを活用していきたいと思っています。GCPのカンファレンスに行く機会があって、いくつかセッションを聞く中で、現在担当しているプロジェクトでもDevOpsなどを積極的に取り入れていくべきだと感じました。自動デプロイやカナリアリリースなども試してやっていきたいですね。

菊地　今はメインでAWSを使用していることから、アプリ上でAWSとGCPの両方が稼働するシーンがあります。もっと設計を最適化することで、アプリのAPIでFirebaseやGCPで成立する部分はGCPにしていきたいと考えています。あとはFirebaseのCloud Firestoreもβ版からバージョンが上がってきているので、我々の開発にぜひ取り入れたいと考えています。

長沢　システムにおいての「交換のしやすさ」が重要だという話しをしましたが、まだまだできていない部分が多いです。比較的最近に作ったサービスでは「交換のしやすさ」は考慮されていますが、メインの部分はまだまだ道半ばなので、今後も継続して刷新していきたいです。

同様にコンテナ化もまだまだ一部しか実現できていません。「交換しやすい」環境を拡大していき、エンジニア陣が開発しやすい状態を整えたいと思っています。

取材：megaya　 megayaのブログ