AWS導入～スケールまでの変遷を事例に学ぶ - コンテナ化のために「みてね」が選んだ構築戦略
これからAWSを導入する、AWSに入門するといった方に向け、AWSの導入のための基本的な戦略や考え方を事例で紹介します。多岐にわたるAWSの機能をいかに活用するか。サービス立ち上げから、その後のスケールまで、実際の現場でどのようにAWSを活用しているかを、株式会社ミクシィで「みてね」のインフラをリードする清水勲さんが語ります。
167
今や全世界のWebを支えるクラウドとして欠かせない存在となったAWS（Amazon Web Services）。さまざまな規模、目的のWebで活用されている中、持続的・永続的なサービス設計・開発・運用をするには、日々の情報収集と、時代に合わせたアップデートが求められます。
今回、株式会社ミクシィが提供する「家族アルバム みてね」でのAWS活用事例をもとに、AWS活用のヒントと勘所を一緒に探りましょう。
みてねは2015年4月にリリースされ、2019年11月現在、600万ユーザを突破し、日本国内だけではなく、海外での利用も増え続けている写真・動画共有サービスです。その急速な成長は、安定・堅牢なインフラが支えています。
今回お話を伺ったのは、株式会社ミクシィ みてねのSREとしてサービスのインフラ管理をリードする清水勲（しみず・いさお／ 
これからAWS導入を検討している担当者、また、スケールにおけるポイントを知りたいエンジニアへ、最新ノウハウをお届けします。
清水 勲さん：株式会社ミクシィ みてね事業部 開発グループ SRE 。2003年にSIerに入社。その中で自社プロダクトの開発チームに参加し、Webアプリケーション開発に関わる。その延長として2009年にAWSに触れ、インフラエンジニアとしてのキャリアを積む。2011年、株式会社ミクシィに転職。SNS「mixi」のインフラ運用チームとして、基盤開発・運用保守を行う。その後、2014年にモンスターストライクチーム、2018年2月に現在のみてねチームに異動し、SREとして活躍する。
- 安定・堅牢なインフラが支える「みてね」。AWS導入の背景
- 次のフェーズに進むためのアーキテクチャ変更へ
- みてねコンテナ化への道～AWS機能のアップデートとコンテナ化のメリット
- ここだけは押さえておきたい！AWS導入にあたってのポイント2020
- 【まとめ】みてねのAWS選択時のポイント
- 2020年に向けて、これからのみてねのインフラとAWS
安定・堅牢なインフラが支える「みてね」。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月、私が主導する形で、みてねのインフラにおけるコンテナ化がスタートしました。
みてねコンテナ化への道～AWS機能のアップデートとコンテナ化のメリット
エンジニアHubに会員登録すると
続きをお読みいただけます（無料）。
続きをお読みいただけます（無料）。
登録ボタンを押すと、利用規約とプライバシーポリシーに同意したことになります。
登録のメリット
- すべての過去記事を読める
- 過去のウェビナー動画を
視聴できる - 企業やエージェントから
スカウトが届く