このページの本文へ

業界を知り、業界をつなぐX-Tech JAWS ― 第6回

コネヒト島田CTOが語るインフラ仕事をなくすまでの長い道のり

「ママリ」を支えるコンテナはチームみんなで育ててきた

2018年03月22日 10時00分更新

文● 大谷イビサ/TECH.ASCII.jp

  • この記事をはてなブックマークに追加
  • 本文印刷

2018年1月25日に開催された第2回 X-Tech JAWSでコンテナの導入を語ったのはママ向けアプリ「ママリ」を展開するコネヒトCTOの島田達朗さん。「日本のママをコンテナで支える」というタイトルで講演した島田さんは「インフラエンジニアの仕事をなくす」をテーマに、アプリケーションエンジニア主導のコンテナ運用を実現するまでの道程を説明した。

EC2 1台から自前オートスケーリング、Elastic Beanstalkへ

 最近CMも放映されているママリは、ママ向けのコミュニティとメディアを統合したアプリで、KDDIグループのコネヒトが開発・運用を担当。2018年1月で開始から4周年を迎えている。2016年に出産したママの5人に1人に使われるくらい知名度が高く、月間閲覧数は約1億回、月間利用数約600万人にのぼるという。「Instagramもきちんと運用しており、おかげさまでフォロワー数も約23万人になった。#ママより#ママリの方が投稿数が多い」と島田さんはアピールする。

コネヒトCTOの島田達朗さん

 そんなママリの成長を長らく支えてきたのがAWSだった。サービス立ち上げ時期はLAMP構成のEC2 1台という潔い最小構成。2週間でアプリを作って、デプロイもサーバーにSSHで入り、メンバーに声を掛け合う温かい手動デプロイだった。そもそもサービスが伸びないと安定したインフラも必要ないためこうした構成だったが、創業当初からAWSの恩恵は受けていたという。「TV放送に数秒露出しただけなのに、一瞬で数千ダウンロードになって焦った。でも、AWSのスケールアップで無事にさばけた」と島田氏は振り返る。また、当初は学生起業だったので、スモールスタートできるAWSの従量課金は助かったようだ。

 とはいえ、EC2 1台は「思いっきり単一障害点(笑)」(島田氏)で、データベースの運用も難しかった。スケールアップ時にサービスを止めなければならないなど、とにかくつらみが多すぎたため、サービスの成長とともにEC2のデータベースをRDSに移行。ELBのロードバランシングを用いた自動オートスケーリング環境を導入し、各種マネージドサービスの導入も進めていった。

 しかし、自前のオートスケーリング環境でもAMIやオートスケールの管理が大変だったため、次はElastic Beanstalkへ移行。「AMIやAutoScae Configからの悩みからは解放され、なにより一度構築すればアプリケーションに必要な要素をさくっと作ってくれ、そのセットを丸っとコピーできる」(島田さん)という点が魅力的だったという。

ECSを用いたDockerコンテナをみんなで育ててきた

 ただし、Elastic Beanstalkは概念がやや独特。ローカル環境で再現するとElastic Beanstalk用にカスタマイズされたAmazon Linuxになるため、カジュアルに検証できないという悩みもあった。さらに使っていたVagrantのローカル開発環境でVMが壊れやすく、動作が重かったこともあり、いよいよコンテナにたどり着くことになる。「コンテナなら環境の作り直しも楽だし、複数のサービスを立ち上げてもVMと比べてCPUを圧迫しない。ローカル環境をそのまま本番に持って行けるので環境差異も生じない」といったメリットがあった。

Elastic Beanstalkのつらみ

 そもそも島田さんが描く理想郷とは、インフラが属人化しないこと。当初は島田さん1人で担当し、その後1人増えたとはいえ、サービスの規模に対してインフラ運用のメンバーは少ない。そのため、ミドルウェアやOS、プラグインまで含めた設定ファイルがすべてGitで管理され、デザイナーでも、開発者でも、同じ環境が簡単に立ち上げられることが望ましい。また、本番環境も開発環境と同じイメージからデプロイされ、両者に差異のない状態を作れれば理想だ。そこに近づくため、ママリのコンテナ導入がスタートした。

 Amazon ECSを用いたDockerコンテナの利用は、まず特定メンバーで小さくテストしてもらい、ニーズをすべて洗い出した。「たとえばDocker for MacとVM on Macのどっちがよいのかなどを検証し、Docker関連の課題を1つ1つつぶしていった」(島田さん)。検証が済んだところで利用メンバーを拡大し、ハンズオンを実施したり、FAQも用意した。最後はアプリケーションエンジニア側からDockerファイルの更新をプルリクエストしてもらい、インフラの持ち物ではなく、みんなで育てていくものという意識を植え付けたという。

インフラエンジニアの仕事をなくしたい

 結果的に新サービスを自らDockerで作り始めるアプリケーションエンジニアも現れ、Dockerファイルにミスがあった場合にもメンバーが積極的に修正点を指摘するようになった。Amazon ECSを用いたコンテナの運用に関して島田さんは「ボトルネックが解消できた。インフラのブラックボックスは解消し、アプリケーションエンジニアがDockerファイルを書き換えることで、環境構築も容易になった」と評価する。

Dockerfileをみんなで育てる

 そんな島田さんが注目しているのはサーバーレスでコンテナを管理できる「AWS Fargate」だ。「ECSを使っていても、外側のEC2インスタンスを意識しないといけないのは、やっぱり課題。1つのインスタンスの中に、何個コンテナを立てられるのか、リソースをどう割り当てるのか、考えるのはやはり面倒。Fargateはよー!という感じ」と期待を語る。

 こうしたFargateの導入も含め、コネヒトとして2018年に目指すのは「インフラエンジニアの仕事をなくすこと」。「コンテナ導入の過程でも、なんだかんだ旗振り役のインフラエンジニアは必要だった。でも、今のコネヒトであればアプリケーションエンジニアだけでインフラまでカバーできると信じている」と島田さんは語る。

カテゴリートップへ

この連載の記事