エンジニアHubPowered by エン転職

若手Webエンジニアのための情報メディア

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

多くの開発に導入されるクラウドサービスですが、LIFULL社では、AWSとGCP、両サービスを同時に使用しているそう。同社のインフラの変遷と、併用の背景を聞きました。

インフラ構築における技術的な選択肢はさまざまですが、なんらかのクラウドサービスを活用するということは多くのエンジニアが検討する手段でしょう。

昨今ではクラウドサービスは多くの企業から提供されており、エンジニアにとって多様な選択肢が提供される一方、どのサービスを選ぶべきかという悩みもあるでしょう。筆者の周りでも「クラウドを導入しようと考えているが、AWSとGCP、どちらを使おうか」という悩みを聞くことは枚挙に暇がありません。

今回お話を伺った、不動産・住宅情報を扱うLIFULL HOME'Sを展開する株式会社LIFULL(ライフル)では、AWSとGCPの「どちらか」ではなく両者を併用しつつサービスを運用しています。その背景には「技術トレンドの移り変わりが早い時代だから、AWSやGCPなどの技術をそれぞれ、いつでも使えるようにしておくべき、という思想がある」と同社CTOの長沢さんは語ります。

従来オンプレミスで構築されていた同社のサービスインフラは、2015年頃にAWSを導入し、同時に「マイクロサービス化の推進」をしてきています。こうしたインフラの変遷の中で、クラウドサービスをどのように選び、そしていまなぜ、AWSとGCPを併用するのでしょうか。

長沢 翼さん(写真右)
株式会社LIFULL CTO。2008年にエンジニアとして新卒入社。入社後は、「HOME'S(現LIFULL HOME'S)」の不動産売買カテゴリの開発、iPhoneアプリの新規開発を担当。技術を支えていく上で幅広い分野に携わりたいという想いから、次第にバックエンドの開発にシフトし、API基盤の刷新を行う。その後、インフラ寄りの業務にシフトし、現在はAWS導入、オンプレミスからの移行やその他技術基盤の開発に従事する。
衛藤剛史さん(写真中央)
株式会社LIFULL 新UX開発部 デバイスソリューションユニット 開発2グループ グループ長。SIerでのエンジニア経験を経て、2014年に中途入社。LIFULL HOME'SのAndroidアプリのリニューアルプロジェクトに参加し、その後はAndroidアプリ開発・バックエンドAPI開発運用を担当する。現在はAndroid開発チームのエンジニアマネージャーとして従事。
菊地 慧さん(写真左)
株式会社LIFULL 新UX開発部 デバイスソリューションユニット TechLead グループ。学生時代には、ドコモカップ東北iアプリコンテストで特別賞を2度受賞。2014年にエンジニアとして中途入社。入社後は、LIFULL HOME'Sの Android アプリ開発を担当。現在は、アプリ部門のTech Lead業務を務めつつ、GoogleのAR技術「Tango」を活用したアプリ開発、かざして検索のPMやAndroid開発を担当する。

AWSとGCP、「どちら」を「どうやって」使うか

——AWSとGCPを併用されていると聞きました。両サービスを導入した背景を教えてください。

長沢 AWSを導入したのは、2014〜2015年くらいです。それ以前はオンプレミスでサーバを運用していました。現在では開発の粒度を下げるべく、マイクロサービス化も進めています。現在は事業系システムのほぼ大半はAWSで稼働しています。

一部ではGCPも利用していますが、それらの機能を会社として「GCPを使おう!」と打ち出したわけではなく、一部のチームで「GCPのこのサービスが便利そうだ」と、自然発生的に徐々に使われはじめた印象です。

——AWSとGCPを併用する上で、両サービスの使い分けはどのように設定されているのでしょうか。

長沢 先ほどお話したようにAWSが多いのですが、使い分けに関しては、特に明確な区分はありません。併用の例を挙げると、あるAPIの機能をGCPで作成し、それをメインのAWSにあるサービスから叩く、という組み合わせで利用していることもあります。

また、マイクロサービス化を実施していく上で、技術選定はチームの自発性に委ねていますので、その中でGCPを利用しているシステムもありますね。新事業を開発しているチームではそのサービスの一部をGCPで開発しているところもあり、どのサービスを活用するかは、チームによってさまざまです。

——具体的にGCPはどういった開発で使用されているのですか。

衛藤 機械学習系やスマホアプリ開発などで利用されていることが多いです。

例えばLIFULL HOME'Sでは、不動産会社様が、部屋の画像をアップロードする機能があります。画像は家屋の外観や、部屋内部、あるいはキッチンだったりと多様なのですが、こうした画像を自動で判別して、適切なタグ付けを行っています。この機能はGoogle App Engine(GAE)を基盤として、Cloud AutoML Visionで機械学習を行い、Google Cloud EndpointsでAPIを管理するようにしています。

——機械学習系はAWSよりGCPのほうが利用しやすいという判断でしょうか。

衛藤 条件や好みにもよると思いますが、Googleが「AIの民主化」を標榜しているだけあって、機械学習系のサービスには力は入れているなと感じます。精度も良好ですし、AutoMLの「誰でも簡単に機械学習にアプローチできる」点は優れていると感じます。

「AIの民主化」は「GoogleCloudNext’17」で提唱された。

——「機械学習系ならGCPを使う」というような切り分け方をしているのでしょうか。

長沢 いえ、明確に切り分けを設定しているわけではありません。しかし、機械学習系のサービスを開発するとき、そのときの用途ではGCPが自分たちのサービスにマッチし、結果として採用されています。AWSやAzureも使ってみましたが、タイミングや機能としてハマったのがGCPだった、ということが導入の背景にあります。

——では、アプリ開発においてGCPを利用されているのはどういった理由からでしょうか。

菊地 アプリチームでは2016年ごろからFirebaseが導入されはじめました。LIFULLでは比較的早い時期からFirebaseを開発に取り入れていたことが、GCPを導入した背景にはあるんです。

衛藤 メインはAWSを使用していますが、Firebaseはモバイル開発との相性が良いので、導入しているサービスは増えてきています。

——やはりFirebaseとGCPの相性はいいのですね。

菊地 そうですね。FirebaseもGoogleのサービス*1なので連携がしやすいというのはあります。解析基盤やイベントからの連携だったり、作ろうとすると苦労する部分が簡単に作れるようになりました。

アプリエンジニアの菊地さん。

——AWSとGCPに同じような機能があり、双方を比較した上で決め手となる判断材料はどこにあるのでしょうか?

長沢 解決すべき技術課題によって変わってくると思います。今は両サービスともに機能が充実しているので、AWSとGCPを比較して、「明確な差」を感じることは少ないです。ですから、実際に触ってみて自分たちのサービスに合うかどうかが、判断材料となるでしょう。また、コストの多寡ももちろん判断材料のひとつです。

——コストの比較は確かに重要ですね。過去、コストを理由に導入サービスをスイッチした事例はあるのでしょうか。

長沢 Amazon Redshiftを使っていたところを、GCPのBigQueryに移行したことがあります。両サービスを比較し、弊社の場合ではコストダウンができることが明確だったんです。また、ほとんどのチームがGoogle Analyticsを利用しているので連携のしやすさに優れており、マーケティングのチームから要望があったことも理由の一つです。

サーバの肥大化を阻止するべく、オンプレからAWSへ移行

——さて、ここからは貴社のサービスのインフラ設計の変遷と、クラウドサービスの関係を伺いたいと思います。オンプレから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のブログ

*1:Firebaseは2014年10月にGoogleに買収されている。