メルカリは日米英で異なるインフラを採用――メルカリのインフラの変遷を ソウゾウ 鶴岡達也さんに聞く

クラウドネイティブ時代のデベロッパー生存戦略 第4回（前編）

US版メルカリではAWSを採用、クラウドの柔軟さが日本以上に重要

Ryuzee.com 吉羽龍太郎さん

吉羽　さくらインターネットのサーバの後はどんな構成に？

鶴岡　その後は、さすがに100万ユーザーを超えてくるとデータベースが遅くなる問題が頻発しはじめたんですね。そのころ、元mixiで負荷対策の経験が豊富な森本に、インフラの面倒を全部見てもらうことにしました。つまり、サーバサイドのエンジニアが見ていた時代から、インフラのチームとして見る時代になっていったんです。

吉羽　そのチームは、今何人くらいいるんですか？

鶴岡　6人です。

吉羽　その頃はもうクラウドに移行し始めたんですか？

鶴岡　メルカリのJP（日本版）は、今もさくらなんですよ。構成は、まるっと変わっているんですけどね。そのあとメルカリのUS（米国版）が始まりました。

吉羽　US版がAWSなんでしたっけ？

鶴岡　そうです。USがスタートする際、専用サーバも調査したのですが、安くないし、クラウドの柔軟さが日本以上に重要でした。

　スケールも大きいし、どういう増え方するのか予想がつかないので、それに対処できるようにということでAWSを使うことになりました。

吉羽　その時はGoogleやAzureを使おうという話にはならなかったのでしょうか？

鶴岡　なかったですね。3年前なので、当時のGoogle Cloud Platform（GCP）はまだそこまでメジャーじゃなかったんですよ。

吉羽　Azureもエンタープライズ向けのイメージが強かったですね。

鶴岡　AWSの経験者はたくさんいたので、触れる人がいるという安心感がありました。

吉羽　一貫しているのが、自分たちでできる技術を選んだということですね。今USと日本は、アーキテクチャはだいたい同じでしょうか？

鶴岡　はい、同じです。

吉羽　では、ハコがどこにあるかの違いぐらいっていうことですね。

鶴岡　AWSには多くの尖った機能がありますが、それに依存すると、USでしか使えないコードになってしまうので、AWS特有の技術は極力使わずにやっています。

吉羽　Amazon S3やAmazon SQS（Simple Queue Service）もあまり使ってないですか？

鶴岡　疎結合にできるものはインターフェースを差し変えれば対応できるので結構使ってます。

吉羽　DynamoDBは？

鶴岡　代替する技術に切り替えられないので使っていません。

　今、SRE（Site Reliability Engineering）のチームは日本にありますが、JPとUS版両方見ています。次はUK（イギリス）に展開していくんですが、UK版はGCPになります（UK版は3月15日にサービス開始済）。

ログ解析はBigQueryへ、Googleの底知れなさが感じられるキラープロダクト

吉羽　Treasure Dataを使っていたのは、当時はBigQueryが無かったからという理由とのことですが、その後BigQueryに変わっていったんでしょうか？

鶴岡　そうですね。Treasure Dataはストレージ容量が従量課金ではなかった点と、クエリを専有するコア数に応じて課金する形になっていたので、クエリの実行ユーザが増えたときにコアが不足する問題がありました。BigQueryは、それと比較すると極めて安価で、パフォーマンスも圧倒的に優れていました。

吉羽　BigQueryはGoogleのキラープロダクトという感じですよね。ハコモノはAWSかAzureだけど、解析系はBigQueryを使うっていうのは、サービス系をやっている方の定番でしたよね。あまりRedshiftを使っている人がいないという印象がありました。BigQueryとRedshiftはアーキテクチャが違いますよね。

鶴岡　そうなんですよ。Amazonの技術は、データセンターがあって、みんなが使っているのと同じサーバがたくさん並んで、その上に構築されてる技術というイメージ。サーバ下のネットワークや裏側がなんとなく想像がついて、パフォーマンスの制約が見えてくる面がありましたが、Googleはそこがもう独自の技術というか、謎に包まれていて。

吉羽　確かに（笑）。

鶴岡　BigQueryは、データも容量制限なくクエリもいくらでも投げられる、もう底知れなさがありますね。