US版メルカリではAWSを採用、クラウドの柔軟さが日本以上に重要
吉羽 さくらインターネットのサーバの後はどんな構成に？
鶴岡 その後は、さすがに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は、データも容量制限なくクエリもいくらでも投げられる、もう底知れなさがありますね。
