サーバーサイドの技術スタック・アーキテクチャ総ざらい
Nobutoshi Ogata 氏（以下、Ogata）：みなさん、こんばんは。「サーバーサイドの技術スタック・アーキテクチャ総ざらい」ということで、お話しさせていただこうと思います。よろしくお願いします。
はじめに、タイトルの通りサーバーサイドで使っている技術スタック、アーキテクチャに関してざっくりご紹介します。SmartNewsがどのようにニュース記事などを選定しているのか、そういったアルゴリズムの話は、申し訳ありませんが今回は一切お話ししません。
まず簡単に自己紹介をさせていただきます。改めまして、尾形と申します。
現在SmartNewsのSREチームのエンジニアリングマネージャーをやっております。
入社は2015年なので、今年で丸4年経ちました。入社して開発基盤やインフラ周りの整備をやりつつ、次の年から当時はなかったSREチームを立ち上げて、マネージャーをやっています。
まずはSmartNewsについて、ご説明させていただきます。
SmartNewsは、スマートフォン、タブレット向けのニュースアプリで、おかげさまで日米で5,000万ダウンロードを突破し、月間アクティブユーザーも日米で1,000万人以上(※2)に成長しました。（注： App Annie, May 2018 date）
SmartNewsをお使いいただけている方は、どのぐらいいらっしゃいますでしょうか？
（会場挙手）
ありがとうございます！
先ほどからチラチラと出てきているマスコットキャラクターは「地球くん」という名前で、とても愛されています。では、中身に入っていきます。
SmartNewsの技術スタック
まず、技術スタックに関してです。SmartNewsは主に2つの配信基盤からできておりまして、ニュースを配信する部分と、広告を配信する部分。これは別々のプロダクトになっています。
今回はニュースの配信基盤にフォーカスしてお話ししたいと思います。
基本的な技術スタックなんですけど、ほぼすべてAWSで動いています。OSはAmazon Linuxを使っています。コンテンツをデリバリーするCDNとしてはAkamaiを使っていて、ごく一部はCloudFrontを使っています。WAFに関してもAkamalのWAFを使っています。
プログラミング言語は、Java8とJava11という感じで、徐々に8から11への移行を進めています。9割方Java8、Java11で、残り10パーセントはRubyやGolang、Scala、Kotlinを使用しています。
ここではオンライン処理とDMPの2つに分けて説明します。オンライン側の処理はAWSのロードバランサーを挟んで、そこにオートスケールグループを作り、その下でEC2のインスタンスが動くという、ごく普通の構成です。
中身としては、リバースプロキシにnginx、JavaはSpring Bootで作られていることが多いです。embedded Tomcatをそのまま使っています。
コンテナはどうしているかと言うと、今のところはECSを使っています。ECSはわりと出てすぐに使い始めていて、当時は今のようにECSの便利機能がなかったので、そのあたりは自分たちで作りこんでいます。nginxやConsul Templateを使って、動的に名前解決しサービスディスカバリーしていくところも、すべて自力で作りました。
EKSに関してはまだプロダクションでは使っていませんが、現在検証中です。
次にDMP、データマネジメントプラットフォームです。ログを集計したり分析する基盤なんですが、基本的にEMR、Hive、Prestoあたりの技術を使いつつ、ジョブのマネジメントとしてAirflowを使っています。
BIツールとして、ChartioやSuperset、Jupyterを使っています。
インスタンスのプロビジョニングは、基本的にはAWSのAMIイメージに共通で必要なものは全部突っ込んで送るようにやり込んで使っています。あと、インスタンスにタグを付けているんですが、そのタグによって役割が決まって、それによって自律的に必要なものを自分でプロビジョニングしています。
成果物のデプロイに関しては、AWSのCode Deployを使っています。ツールとしては、itamae、Terraform、CircleCI、Jenkinsなどを使っていて、最後のVAddyという技術はCIに組み込んで使えるオンラインの脆弱性検査ツールになってます。
監視や通知はどうしているかというと、Datadogで統一しています。Datadogで監視を行っていろいろ設定をしているのですが、一定のしきい値を超えたり、本来出るべきでないログが溢れてしまう、あるいは一定期間出るべきログが出ていないものを監視して、必要であればPagerDutyを使って開発者の電話を鳴らす仕組みになっています。
あとはRunscopeというツールを使っています。これは外形監視ツールで、外から実際にREST APIをたたいて、正しい応答が返ってきているかを外部から確認するためのツールです。
New Relicに関しては、APIですね。アプリケーションに組み込んで、どのようなSQLが使われているかであったり、この関数はどのくらい時間がかかっているかといったことを計測するツールも組み込んで使っています。
ちょっと珍しいかもしれないものとしては、PipelineDBを一部で使っています。先ほどニュース側と広告側があるという話をしましたが、ニュース側に関しては内部の通知しか使っていません。あとはHazelcastを使っていて、これに関しては後ほどご説明します。
ニュースが配信される流れと規模
次にニュースがどのように配信されるのか、データの流れや規模をご紹介していきます。
この図を見ても何がなんだかわからないと思いますが、ざっと説明すると、上が実際にユーザーがどんな記事を見たか、どんなアクションを起こしたかという、ユーザー行動ログを集める部分です。
真ん中が記事の検索やパーソナライズされたデータをユーザーに渡すための部分です。こちらが一番メイン側の部分になります。こちらは実際にパブリッシャーの方々から提供されたニュースをインデクシングして、われわれのデータベースに取り込みをしている部分です。
最後に、下の部分はユーザーにプッシュ通知を送るための基盤部分になります。
では、数字的にどんな感じかざっと並べてみました。この数字を見てピンとくるかどうかはわかりませんが、だいたいこんな感じです。
CDN側ではこんな感じです。これは単位がbitなので、若干大げさかもしれませんが、規模的にはこのくらいのデータを扱っています。
Onlineのアーキテクチャ
続いて、ニュース配信部分のアーキテクチャについてお話します。
基本的にメインのサービスは、APIゲートウェイ的な役割を果たすAuto Scalingグループが中心にあり、アプリケーションロードバランサーの下に配置されて動きます。検索エンジンでインデックスされた記事が検索可能な状態になって、サーチエンジンを使って記事を探し出します。
基本的にはAuto Scalingグループを積極的に活用するようにしていて、Auto ScalingグループとLambdaやSNSを組み合わせて、スケールアウト、スケールインはほぼ自動的に動いてくれるようになってます。
当然スケールアウト前提なので、そもそもアプリケーションの作りがスケールアウトできるようになっているのは、言うまでもないことではあります。
サーチエンジンなんですが、ここはAWSでもスケールが難しい部分で、がんばってキャッシュを2層作ってなるべく負荷を上げないようにしつつ、オフライン処理でキャッシュの処理も絶えず更新する作りにしています。
パーソナライズ部分なんですが、当然人によって中身が違います。この辺はキャッシュを作ること自体非常に難しいので、Hazelcastを使っています。要はインメモリーデータグリッドのような感じです。
大量の request とそれに伴う非同期処理を効率よくさばく・わかりやすく記述するため Reactive Streamsを採用し、さらに自律的に自分自身の負荷の状況を見て処理の内容を飛ばしたりといったことをするようにしています。
SmartNewsのこれから
最後になりますが、プロダクトや組織、あるいはサービスの提供範囲もどんどん成長していっています。もっとスケーラブルで安定した基盤が必要になってくる状態になってきています。USとも開発を進めていますので、時差も超えて、もっと簡単に、もっとスムーズに開発できる環境を、これから整えていく必要があると考えています。
そのためには、仲間がより多く必要であると思っているので、ぜひ興味を持っていただければと思います。
ここに現在募集している職種の一覧が掲載されていますので、ご興味のある方はここを見ていただくか、この後の懇親会で社員にお声がけいただければと思います。
手前みそではありますが、主要な社内制度を持ってきました。けっこういろいろな手当てが揃っていて、非常に快適に仕事をしやすくなっているのではないかと思います。渋谷駅から徒歩10分と書いてありますが、ここに入れるべきではなかったですね……すみません（笑）。
（会場笑）
福利厚生に関しても、「ここはどうなってるの？」という質問があれば、後ほどお声掛けいただければと思います。
それでは、ご清聴ありがとうございました。
（会場拍手）
