ぐるなびのインフラを支える技術 〜AWSの話をしていたのに、インフラとしてのキャリアの話になった

TOP ぐるなびのインフラを支えるエンジニア、岩本と飯田。

今回はちょっと趣向を変えて、当社インフラストラクチャーサービスグループの岩本と飯田にぐるなびのインフラ全体からキャリアまでをざっくばらんに話してもらいました。

まずは飯田さんの質問から始まります。

ベンダーロック正直どうなんですか

飯田 これまで物理サーバで動いていたものが 仮想マシンやコンテナに代わり、オンプレミスからパブリッククラウドに向かっていますよね。

ぐるなびは 今 AWSを主に使っていて、今後もGCPとか色々なクラウドを使っていくと思います。ただ、AWSを使っているがためにベンダーロックされてしまって、例えばGCP使いたいけれど移行しづらいからAWSに寄ってしまう、なんてことがあるのではと思ったりもします。

そこらへんどう考えますか。

岩本 AWSを使い始めると、他に行きづらい反面、AWSをしっかり使っていかないとAWS上の恩恵を受けられないから、もともとなんでクラウドを使い始めたかがポイントじゃないかな。

コスト削減というところからだと、今みたいな発想になってしまうと思うけど、開発者が開発効率をあげたり、ビジネスのサイクルとシステムのサイクルをなるべく近くする、というところにおくと、スピード感や俊敏性の恩恵をAWSから受けられるならAWSを使わないといけない。

例えば、ビジネス側が急遽これがやりたいとなった時に、開発側がそれをやるにはこれだけのリードタイムが必要なんだと言うと、それだけ時代に取り残されてしまう。

AWSのサービス1つ1つをSaaSみたいなサービスとして使った時に、アプリケーション側は現時点ではDockerで動いていれば別にどこで動いていようが変わらないと思っていて。それはオンプレミスのKubernatesの中で動いているコンテナのアプリケーションを、AWSのEKSだったりECSへ動かすとなった場合でも、実はそこまで難しくはないと思っている。

我々は、AWSが使いたいからというより、開発効率が一番良くなるタイミングを考えた上での選択をすればいいんじゃないかな。ロックインするからやめておこうになってしまうと、逆にクラウドに行く意味がなくなってしまう。

オンプレミスからAWSに行くのも、多分同じハードルだと思っている。オンプレミスで使っている共通システムをAWSのマネージドサービスに置き換えるだけだから、言うほどアプリケーション側の改修も多くなく使えるはず。

インフラとしてはAWSは1つのツールとして考えていて。

例えばGoogleMapを使っているけれど、別のMapサービスを使っていこうとなった時に、アプリケーション側のタイミングで切り替えていく。それと同じ感じで切り替えてもらえばいい。

f:id:gnavi_developers:20190611161632j:plain

岩本
インフラストラクチャーサービスグループのグループ長としてマネジメントをしつつ、インフラエンジニアとして第一線で現場をリード。以前は、backpackerとして世界を旅することが趣味だったが、今はグアム旅行で満足している。



飯田 クラウドって今色々あると思うんですけど、なぜAWSだったのか気になっていたんですが。

AWSは●●●

岩本 それは2年前くらいに検討し始めた時に、AWSが圧倒的にサービス量が多い、選択肢が多いって言うのが1つ大きかったんじゃないかな。当時は、早くサービスを立ち上げられることに主眼を置いていた。

アプリケーションを1から作っていく時に、認証が必要だから認証するためのものを用意しないといけないとか、データベースの可用性を考えるために可用性を意識したものを作らなければいけないとか、1つづつ考えてインフラ提供をしていかないといけないけれど、その高い可用性だったり信頼性だったりを選択できるものが圧倒的に多かったのがAWSだったのかなと。

これだけサービスが多ければ、AWSを使えば開発はもっと開発効率をあげてリリースもできるようになるのではと思ったことがきっかけ。

マルチクラウド構想になっているから、基本的には今でももちろんGCPを使おうと思えば使えるし、azureでも全部繋げられるようになっている。Alibabaも使えるようになっているし。

ただ、現時点でGCPを使って何かやるというよりは、GCPのこれが使いたいっていう人たちの意見を吸い上げて、そこをどういう風にネットワーク的に繋げていくのか、それがインフラの仕事なんじゃないかな。

f:id:gnavi_developers:20190611162156j:plain

飯田 入社当時、AWSをちょっと使っていたのでAWSの機能の多さは知っていて、多分そういう背景があって選定されたんだろうと何となく思っていました。

だからこそ機能だけで比較してAWSを選んだ時に、あとあとこっちが伸びたからこっちへいこうとしても行きづらい、なんてことがあるのではと思ったのが質問の意図でした。

でも、今の話で言うと、元々のマインドがクラウドを使う前提だったらそういうことではないのだろうと思いました。

岩本 そうだね、その後の移行を考えてリリースが遅れるのは多分違うんだよね。

飯田 目的はリリースであって、サービスの提供であるというか。

岩本 そう、いかにユーザ体験の良いサービスを早く出していくかという点で、オンプレミスだとやっぱりスピード感で限界がきてしまう。

例えば、音声だったりIoTだったり機械学習だったりを1から自分たちで作るっていうエンジニアのモチベーションもあるだろうけど、それをみんなでやっていくのはすごいコストで、そこをパッと使ってさっとリリースできる。

それが、サービスとしてビジネスとして成功したら規模が大きくなって、コスト的なところはやっぱり出てくるけど、そんな時にマイグレーションしやすいように、コンピュートエンジンのところはなるべくDockerで作っておいてオンプレミスに持って帰ってこようとか、Auroraを使ってもMySQLで持ってこれるとかは何となく頭に置きながらも、サービス立ち上げ時にはなるべくAWS内のサービスであげる方がサービスリリースは早くなるはず。

ただ、AWSって使ってみるとわかると思うけど、アップデートがすごく多い。

飯田 そうですね、今必死で覚えて、AWS知ったってなっても、多分半年後にはもう全然違う。だから常に追うことがミッションというかみんなの課題というか。

f:id:gnavi_developers:20190611162326j:plain

岩本 そうだね。まあでも事業会社なので、あくまでサービスありきでいいものを提供していくのが仕事なんだけどね。

あとは、これはインフラ目線なのかもしれないけど、クラウド化はコストの可視化がすごく大きいかなって思うんだよね。

オンプレミスだと5年間の原価償却の中でサーバを買ってそのまま使い続けるじゃない。たくさん買ってたくさんのインスタンスが乗ってるから、コスト的には安いかもしれないけれど、5年間使い続けないといけないから、システムのライフサイクルとビジネスのライフサイクルが絶対あってないはず。

例えば、Cassandraを入れた物理サーバがあって5年間使わないといけない、だけどビジネスとしてはそれではなくてこれをやりたい、でもそのサーバを使わないといけないから5年間サービスを保持するって、なにか違う。

そしてたぶん、そのサイクルが以前より早くなっていってるんじゃないかなと思う。

昔はそれでもなんとかなった気がするけれど、今はクラウドを使ったサービスが次々とたちあがるから。ゲーム業界とかそうだと思うけれど、ものすごいサイクルで作っては壊し、新しいものをどんどん生かしていく。中国とかもぜんぜん違うじゃない。新しいサービスがどんどんあがってくる。

要するに、ビジネスと同じライフサイクルにあわせてサービスをまったく同じスケールで3つも4つも壊しては作った4年間があるとして、実はその4年間でかかるコストは5年塩漬けにするのと同じですっていったときに、新しいものがうまれた4年間であって結局利益さえでればいい話じゃない。発想がそっちになってほしい。

インフラの仕事って今後どうなっていくの?

飯田 なるほど。

ここでキャリア相談じゃないですけど、クラウドを使っていく中で、たぶんインフラが今までやってきた仕事ってどんどんオフロードされていて、やる仕事が全然変わってきていて、今後何をメインでやってくのかなって思うんですが、どうですか?

f:id:gnavi_developers:20190611162455j:plain

飯田
新卒入社4年目。コーディングもできるインフラエンジニアとしてサーバやミドルウェアを担当。趣味は野球。ここ数年はあまりできていないのでボールに恐怖を感じている。


岩本 やることなくなるって人も多いしね。不安?

飯田 ぼくはそんなに不安は感じていないですが、ただ、やる仕事がどんどん縮小されていくにつれて、インフラの必要な分母数がかわってきて、その中で君はアプリケーション寄りねとかになっていくと思うんです。当社だけじゃなくて世界的にみても。

そういうときに、今後インフラエンジニアって何を主な仕事としていくのか、何をやっていくのかなって。

新しい技術がでてきたときにそれを率先してやっていくっていうのもあるけど、みんながみんなそれをやってくわけではないですし、何がメインでやっていくことなのかなと。

岩本 そうね、クラウド化したらインフラのやることがなくなるのではって質問を開発者からうけることもあるけど、正直あまりそういう風に考えたことはなくて、むしろやることが増えるのではって思う。

たぶん、飯田君がいま言ったことが近いと思うけど、もっと領域が広くなっていくし。

ぐるなびのインフラの仕事って、サーバだけ渡してはいどうぞではないよね。サーバを渡すときに実際にアプリ側と一緒にアプリケーションの性能をみて、この性能ならこのくらいの台数でいけるとか、この性能ならDBをこう作っていこうとかスケールをこうしようとか一緒にきめていくじゃない。

今やっていることを延長して、もっとネットワークレベルで担っていくような仕事になるんじゃないかな。

例えばグローバルに展開するときに、アプリケーションの性質だったり、リクエストだったり、どんなアクセスどんなデバイスとか考えながらネットワークを作っていくよね。

今までだったら低レイヤーのところだけをやっていればよかったけど、もっとインフラがアプリに寄っていって、アプリ側ももしかしたらバックエンド側でインフラ寄りの人がジョインするのかもしれないけど、アプリケーションとして動かす実行環境を作っていく人たちになるんだろうね。

ただ、ネットワーク機器とかが本当に全部クラウドにいってしまったらなくなるかもしれないけれど、きっと全部いくことを目指すけれど、その先どうなるのかまだわからない。でも今クラウドを使っていてもネットワークのレイテンシとかTCPがどうとか、結局ネットワークの話になっちゃうし、根本をつきつめるとそこをモニタリングするとかインフラとして知らなきゃいけない。

インフラのOpsの仕事は山ほどあるけど、それをクラウドでオフロードさせた先には、もっともっと信頼性が高くてもっともっと早くサービスを立ち上げられて、しかもサービスに影響がなく、ユーザが使いやすいものをしっかり提供していく。

開発者はそんなの気にしなくてもアプリケーションをデプロイしていけば基本的にサービスが立ち上がっていって、今回はこれだけど、次はこのプラットフォームでやってみようって選びやすくなったり。

そこを担うようになるので、ネットワークエンジニアって言葉ではないだろうね。

f:id:gnavi_developers:20190611162703j:plain

飯田 今までみたいに9を増やしていこうみたいな、99.9999・・っていう9をもう一個増やしていくみたいな話でも無くなっていくんですかね。

岩本 あ、そうだね。

今までだったら落ちないために100台用意しようって考え方だったけど、サービスの継続性を考えて、落ちたとしてもサービスとして影響がないものを作れば、別に落ちててもいいはずで。我々のマインドも変えていかないといけない。

サービスとして可用性を求めるもの、例えばユーザが予約をするシーンでいうと、予約が失敗してはいけないけれど、でも失敗しなければ数秒遅延しても大丈夫、とかをしっかり考えられるようになればサイトも作りやすくなるはずじゃない。それを選択できるようにするのがたぶんインフラの仕事なんじゃないかな。

今はアプリケーション側でexception発生したらこうするって色々考えるだろうけど、インフラとして、例えば東京リージョンの一部が遅延したとした時に、Availability Zoneを切り替えてこうしますとかを考えてあげれば、実はアプリ開発者は同じプログラムなんだけど、それににあったレイテンシでしっかり切り替わっていく。

それがモニタリングされていて、それを超えた場合にはまたそれをどうしようって実際にまた考えていくってのをテストして実施いくって領域になっていくだろうから、何者なんだろうね。

スキルセットもかわっていくだろうね。

コードが書けないと運用管理も大変だしね。はじめからコード化しておくことで、そのアップデートにも追従できるようになるからね。

でもこういう人たちしか残れないと思うんだよね。

f:id:gnavi_developers:20190611162741j:plain

飯田 ネットワークだけをやってますっていうとそうですね。

岩本 ネットワークエンジニアはある一定数絶対必要で、クラウド内でももちろんネットワーク機器を設置している方々がいる。その一定数の方に行きたいのかどうかだよね。

これから5Gとか色々なネットワーク的なアップデートが出るはずで、ネットワークの技術は止まらないから、どんどん便利になるじゃない。最近みんなスマート家電の話ばかりしてるけど、結局今の仕組みってただ作り上ネットワークでうまくやってるだけで、今後もっとよくなるはず。

ネットワークの最低限の知識がありつつ、その中でアプリケーションをどうやって使っていくかに活かしてく、そういう幅広い人になっていくんだろうなって思う。

インフラエンジニアの仕事がなくなるって考えは、クラウドにいくと、アプリエンジニアがインフラやる考えが多分あるからだと思うけど、逆だと思う。逆にそこをやってはいけないでしょって。

今(社内で最も使われているのは)PHPだけど他の言語でやってみたら、次のリリースから半分の時間で作れるようになりましたとか、スピードがものすごく早くなりましたとか、開発者にはそういうところで色々チャレンジしてもらって、サービスに対してどうコミットしていくかに注力できるようにしていけたらと思う。

例えばPython触ったことないからやりたくないですって考えだと、むしろ開発者の方がやることなくなるかもしれないね。

インフラはやること増えて忙しくなると思う。はじめの質問のどこの分野をやるんだろうってところに戻るけど、自分がどこの分野をやりたいかも重要かなと。

飯田 まあ色々聞かれますよね。どこやりたいとか。

僕は強いて言うとコンテナ技術がやりたいですね。マイグレーションしやすいとか色々あると思うんですけど、何よりも今一番ホットな技術だと思っているのでやっていて楽しいし、毎日新しい情報が出てくるので枯れてない。そこが楽しいですね。

ただエンジニアとして楽しいだけな気がしますけど、そこが一番モチベーションになっているのかも。

f:id:gnavi_developers:20190611162841j:plain

岩本 当社ではDockerも一部本番で使っていて、今はKubernates一択になってるけど、色々と交代したよね。それは我々が一番いいと思うものをその度に選択しながらやってるからなんだけど。

開発の全体のサービスとしたら本当に一部。そこはDockerで最初から全部作ってくださいってところに、PHPが向いてないとかもあったりするから。今後サービスとしてはなるべく寄せていってもらえれば、クラウド化もしやすいし、オンプレでもしやすい。まあでも実際使ってみて開発しやすいってなった人もいるし、いや別に使いたくないってなった人もいるし。社内でも色々だよね。

基本ぐるなびのインフラは、これやりたいに対して、今忙しいからやめようっていうのはないんだよね。ただ、そういうことやる時はだいたい残業が増えちゃう。

でも、それが本人にとって力がつくしやりたいんだというのがあれば、その気持ちを応援したい。もちろん激しい残業があればちょっと待てってなるけれども。基本的にそれが楽しくて今一番やりたいんですっていうのがあれば。

二人で飲みにいくとほとんどそういう話ばかりしてるよね。なになに今何が楽しいのって話になって、今これ動かしてこうなんですよって。で、これってどうサービスに使えるかなって。

基本的に私マネージャなので、これをどうやってサービスに展開できるかを考えたいんだよね。ていうと、今の飯田くんの発想は、ここだったら向いてるかもっていうのがあって、ただ技術で遊んでるわけじゃなく、しっかり事業会社のインフラエンジニアとしてどうやってサービスに入れられるかがある。

一緒にサービス側にどうやって展開して行こうかってのを考えていきたいね。インフラには昔から結構いろんなものをチャレンジしてきた文化があるからね。

f:id:gnavi_developers:20190611162930j:plain



お知らせ
「焼きおにぎり」は英語で? Alexaで 料理メニューのクイズにチャレンジしてみませんか。