AWS導入~スケールまでの変遷を事例に学ぶ - コンテナ化のために「みてね」が選んだ構築戦略

これからAWSを導入する、AWSに入門するといった方に向け、AWSの導入のための基本的な戦略や考え方を事例で紹介します。多岐にわたるAWSの機能をいかに活用するか。サービス立ち上げから、その後のスケールまで、実際の現場でどのようにAWSを活用しているかを、株式会社ミクシィで「みてね」のインフラをリードする清水勲さんが語ります。

AWS導入~スケールまでの変遷を事例に学ぶ - コンテナ化のために「みてね」が選んだ構築戦略

今や全世界のWebを支えるクラウドとして欠かせない存在となったAWS(Amazon Web Services)。さまざまな規模、目的のWebで活用されている中、持続的・永続的なサービス設計・開発・運用をするには、日々の情報収集と、時代に合わせたアップデートが求められます。

今回、株式会社ミクシィが提供する「家族アルバム みてね」でのAWS活用事例をもとに、AWS活用のヒントと勘所を一緒に探りましょう。

みてねは2015年4月にリリースされ、2019年11月現在、600万ユーザを突破し、日本国内だけではなく、海外での利用も増え続けている写真・動画共有サービスです。その急速な成長は、安定・堅牢なインフラが支えています。

今回お話を伺ったのは、株式会社ミクシィ みてねのSREとしてサービスのインフラ管理をリードする清水勲(しみず・いさお/ 1@isaoshimizuさん。豊富なAWS活用経験をもとに、みてねのインフラ、とくにAWSの活用について、導入背景や実際の運用、これからの展望について、実体験および現在進行中の取り組みについて語っていただきました。

これからAWS導入を検討している担当者、また、スケールにおけるポイントを知りたいエンジニアへ、最新ノウハウをお届けします。

2
清水 勲さん:株式会社ミクシィ みてね事業部 開発グループ SRE 。2003年にSIerに入社。その中で自社プロダクトの開発チームに参加し、Webアプリケーション開発に関わる。その延長として2009年にAWSに触れ、インフラエンジニアとしてのキャリアを積む。2011年、株式会社ミクシィに転職。SNS「mixi」のインフラ運用チームとして、基盤開発・運用保守を行う。その後、2014年にモンスターストライクチーム、2018年2月に現在のみてねチームに異動し、SREとして活躍する。

安定・堅牢なインフラが支える「みてね」。AWS導入の背景

―まず、現在のみてねにAWSを導入した背景について教えてください。

清水 私自身、AWSに触れたのは今から約10年前、前職時代にあるプロダクトを試作する際、サーバにAWSを選んだのがきっかけでした。その当時のAWSは、現在ほど多様な機能はなく、AWS=EC2というイメージの中、オンプレミスではない選択肢として、また、スモールスタートがしやすい環境として注目を集め始めていました。

その後、ミクシィへ入社したのですが、当時はまだ、みてねはもちろん、モンスターストライク(ミクシィが提供するゲームアプリ)もなく、SNS「mixi」のインフラエンジニアとして、サーバ運用管理に関わっていました。そして、モンストチームを経て、2018年2月に現在のみてねチームへ配属されています。

ですから、私自身はみてねの立ち上げに直接関わっていはいないのですが、みてねの開発メンバーの1人がAWSの経験者であったこと、そして、他の選択肢がある中で、開発のしやすさ、規模感、コストなどがマッチしたことが、AWS選択の理由になったと聞いています。

AWSを選択した決め手になったのは次の二点だと言えますね。

  • スモールスタートで立ち上げやすい
  • ブログや文献など、AWSのノウハウに関する情報量が多い

ミクシィとしては、mixi、モンストと非常に大規模なサービスの開発、運用経験がある中、サービス初期からAWSを使った「みてね」は、それらとはまったく異なる運用管理体制になります。また、ゼロベースのプロダクト開発だったという点からも、AWSを選んだというのは、私自身も納得できます。

次のフェーズに進むためのアーキテクチャ変更へ

―AWS採用の背景は、いわゆるスタートアッププロダクトとして王道であったと言えますね。その後、現在はみてねの次のフェーズに向けて新しい取り組みに進んでいると伺いました。そのあたりについて詳しく教えてください。

清水 最新の取り組みの前に、これまでのみてねのアーキテクチャや開発体制について説明します。

みてねはインフラにAWS、サーバサイドにRuby on Railsを採用したサービスです。ユーザ向けのクライアントはiOS/Android(スマートフォンアプリ)およびPC(Webブラウザ)となります。

2019年11月現在、ユーザ数は600万人を超え、日本をはじめ、多言語対応により北米や欧州などワールドワイドで展開しています。

現在のみてねは、大きく3つのエンジニアチームに分かれています。

  • アプリ開発チーム(クライアントサイド/サーバサイド)
  • コンテンツ開発チーム(AIおよび機械学習によるサービス開発)
  • SREチーム(サービス全体の運用保守改善)

私が所属するのがSREチームです。

開発当初は数名のエンジニアによる力技開発

みてねの開発を始めた当時はエンジニアの数は少なくて、チームも複数に分かれておらず、3、4名がフルスタック(すべてを担当する)エンジニアとして、日々開発に取り組んでいました。実は、つい最近(ユーザ数300万人)ぐらいまでは、エンジニアはほぼ全員フルスタックの開発をしていました。

その後、ユーザ数が400万人に近づいたころから、クライアント/サーバサイド開発以外のインフラの運用保守、SREが必要となり、現在の体制になっています。

サービスの規模とクオリティ向上に向けての取り組み

そして、エンジニアチームが細分化し、これからのみてねを考える際に、アーキテクチャの見直しをすることになりました。そのころ、世の中的には、DockerやKubernetesを活用する、いわゆるインフラのコンテナ化が主流になり、また、サービス開発においても、マイクロサービス化の動きが活発になってきたように思います。ちょうど2018年初頭ぐらいでしょうか。

そして、2018年4月、私が主導する形で、みてねのインフラにおけるコンテナ化がスタートしました。

3

みてねコンテナ化への道~AWS機能のアップデートとコンテナ化のメリット

エンジニアHubに会員登録すると
続きをお読みいただけます(無料)。
登録のメリット
  • すべての過去記事を読める
  • 過去のウェビナー動画を
    視聴できる
  • 企業やエージェントから
    スカウトが届く