月間数億のトラフィックをさばいた経験を生かしてschooの技術責任者に

新卒で入った受託開発の会社で9年ほど開発をしていました。使用していた言語はC言語から始まり、C++、Java、などの高級言語やPerl、PHP、Ruby、PythonなどのLight Languageもやりました。この会社で開発の基礎を身につけることができましたね。

その後、GMOグループに転職をして、インフラ運用のエンジニアへキャリアチェンジをしました。当時、ヤプログ！の「しょこたんブログ」で月に数億のトラフィックをさばく経験をさせてもらったのは、非常にいい経験だったなと思います。

GMOで2年ほど働いた後、アッカ・ネットワークスという会社で「zoome」という動画共有サービスを立ち上げるプロジェクトに誘われて企画段階から参加しました。zoomeは当時ニコニコ動画に次ぐ国内第2位のサービスだったんですが、ビジネスモデルの構築に失敗してサービスと会社をクローズすることになりました。会社をクローズする上で、資産計上されるサーバーの処理をやり切る必要があったため、インフラを担当していた僕は最後まで残りました。

その件が一段落した後、gloopsに入りました。インフラの部長として入ったのですが、開発部や企画部の副部長、品質管理部の立ち上げなどを色々と兼務していました。その当時、僕が一番兼務している職が多かったんじゃないかな（笑）。

インフラグループは、入社当時は2〜3名でしたが、最終的には20名まで成長しました。品質管理は未経験だったのですが、開発テストの延長と考え、0からノウハウを身につけ、最終的にはアルバイト・契約社員含めて100名を超えるメンバーになりました。

後継の採用と教育を行い、自分にしかできないことはなくなったので、2014年4月に技術責任者としてschooに参加し、現在に至るまで1人でインフラを見ています。

ぼろぼろだったインフラを、1ヶ月で全て作り直した

参加して最初の1ヶ月でインフラを全部作り直しました。それまではインフラ担当はいなかったので、一言で言うとぼろぼろでした。監視する仕組みもなかったのでそれも作りまして、この時は本当にがっつり直しました（笑）。

ひと通りインフラを構築した後、検索機能の開発を検討し始めました。当時1,000本を超える授業があったにも関わらず、検索機能がなかったんです。ユーザーが出会いたい授業に出会えない状態だったので、これはまずいと思い、優先度を高くして取り組みました。

1日15万通のメール配信を安価に、遅延なく実現するSES

そもそもインフラ自体も危うい状況にあったのですが、メール配信のシステムも負荷に耐えられなくなっていました。具体的に言うと配信の遅延が発生してしまっていました。一時は「授業開始前のリマインドメール」が授業開始後に届くようなことも発生してしまっていたんです。

schooはPCユーザーの比率が6割なので、ユーザーとのコミュニケーションにメールを多用しています。「授業開始前のリマインド」、「お知らせ」、「授業のレコメンド」、が主な使い方で、1日に平均15万通は配信しています。多い時だと25万通くらいですね。それまでは、自前のメールサーバーで送信をしていたのですが、ユーザー数の増加とともにメールが増えて、パフォーマンスが出なくなっていました。また、自前のサーバーの運用コストも高くなっていたので、新しいシステムを構築することにしました。

「メール　バルク」でググって、利用するサービスを数時間検討し、AWSのSESを使うことにしました。国内のサービスでもバルクメールを送信するサービスはあるのですが、ASPなので単価が高くカスタマイズが難しい。また、弊社はシステムをほぼ自前で組み立てているので、純粋にメールを送るだけのサービスを使いたいということもあり、AWSのSESを選びました。

バウンスメールの処理を変え、2%→0.02%まで減らすことに成功

AWSを使ってメールを配信する方法は3つあります。

1. EC2というプロダクトを使う方法
2. 小規模に向いている、SNSというプロダクトを使う方法
3. バルクで大量のメールを使う場合に向いている、SESというプロダクトを使う方法

このうち、EC2とSNSは東京リージョンで公開されていますが、SESはまだ公開されてないプロダクトです。ただ、公開されてないとはいえ使っている会社はそれなりにあったため、SESを使ったシステム構築を始めました。SESを使う際に気をつけなければならないのは、「バウンスメール（※）」の処理です。このメールを減らさなければ、AWSから1日に送信できるメールの上限件数がどんどん減ってきます。

（※）何らかの理由で配信エラーとなり、送信者に差し戻されるメールのこと

そこで、「バウンスメール」が戻ってくるのを減らすために、そもそもバウンスになるようなメールを送らないようにする必要がありました。そのために最初にパイプライン化されたキューによる並列バッチの仕組みを構築しました。命令が登録されたキューをバッチサーバーが監視し、各バッチサーバーは登録されたキューに応じて、並列で適切な処理をするような仕組みです。

▼バウンスメールを捌く仕組み

この仕組みにより例えば、メールがバウンスメールとして戻ってきたら、「メールを送らない設定に変える。」というキューを登録し、そのキューを確認したバッチサーバーがユーザーの設定を変更するという処理を実装しました。

具体的には、ユーザー登録をすると、設定画面の中に「メールを受け取りますか？」というチェックボックスが幾つかあるのですが、そのチェックボックスを敢えて外してあげるような処理です。更に、その状態が続くと、ログインした時にトップの上の方に「登録したメールアドレスにメールが送れません。登録をご確認下さい。」といったようなアラートを出す処理も施しています。

こういった裏側の仕組みによって、元々2%弱だった『バウンスメール』の送信率が0.02%以下になりました。

エンジニアに裁量を与え、スクラップ＆ビルドで前進する

SESはまだ当時、β版のような状態でしたが、使用する上で特に不安はありませんでした。schooはスタートアップなので、事前に安定性や冗長性をしっかり調べるよりは「まずは試してみること」を重視しています。「だめだったら別のサービスを使えば良い」というスクラップ＆ビルドの考え方ですね。

そもそもエンジニアのモチベーションが上がる時って、新しいものを触るときなんですよ。それを会社側が制限したらモチベーションも下がりますし、新しいものも生まれません。

なので、エンジニアに裁量を与えて、どんどん新しいことにチャレンジしてもらっています。使うツールやシステムも自由ですし、開発側の裁量が大きいのがschooの特徴です。

また開発にあたってもチーム内にディレクターはいません。企画やプロダクトオーナーからは「こういう目的の機能が欲しい。」といった状態でしかオーダーが落ちてこないですね。そこから仕様、実際の機能や画面に落とし込むのもすべてエンジニアとデザイナーで行います。

1日100万件のメールを送れる容量までを構築済

現在は1日15万件〜25万件のメール配信ですが、バウンスメールを適切に処理しているため、単一リージョンの利用だけで1日100万通くらいは送れる状態は構築できています。まだまだ使い続けられますね。とは言え今はとても満足して使っていますが、出来れば東京リージョンで公開して欲しいです。距離が近くなれば短時間で送信できるメールが増えると思いますので、今後に期待しています！