DeNAが目指すこれからの分析基盤　2020年代に向けたインフラのあるべき姿

運用の解説

斉藤克哉氏（以下、斉藤）：ここまでで、分析基盤のシステム的な概要をご説明させていただきました。次に、運用について紹介させていただきます。

運用業務として私たちがふだんどういうことを行っているかですが、先ほどご紹介したArgus、……ダッシュボードですね。あとバルクローダーであるMedjed、それぞれの設定とか、Jenkinsの設定、サーバー運用などを行っています。

Argus、Medjedといった内製のWeb UIに関しては、権限の初期設定を行ったりします。例えば、アナリストの方に「うちの部署でこういった権限を付与した新しいプロジェクト……タスクだったりレポートの集まりですね……をつくりたいんだけど」というような話をいただいた時に、依頼者の方に管理権限を付与した状態でプロジェクトを作るなどです。

その際、BigQueryへの読み書きが発生しますので、サービスアカウントをつくって、鍵を払い出して登録するといった設定も一緒に行います。

Jenkinsの設定も、同じような権限の設定が主です。

オンプレミスのサーバー運用に関しては普通のインフラ運用業務が発生します。脆弱性対応、色々なパッケージのバージョンアップなどを行います。

それらのタスクはGitHub Issueで管理していて、原則として全従業員が閲覧できる設定にしています。当然パスワードや鍵ファイルは、Issueに書くことはできませんので、別の経路でいただくことになります。

Slackでのサポート体制

次に、サポート業務に関して紹介させていただきます。私たちは社内の分析基盤の利用者に向けて、技術サポートを提供しています。ポリシーは、スライドに「分析基盤よろず総受け」と書きましたが、分析基盤についてであれば、まずは「とにかく話を聞いて、対処する」というポリシーです。

サポート対象の多くはデータ分析を行うアナリストの方ですが、先ほどご紹介したようにアナリスト職以外の方がクエリを投げたりするケースもあるので、ビジネス職の方やバックオフィスの方を含む様々な職種や立場の方から相談や問い合わせを受けます。

最近の問い合わせやサポートを行う媒体は、7割以上はSlackになりました。Slackに次いでミーティング、メールといった順番で、お問い合わせをいただくことが多いです。

Slackでのサポートの方針ですが、まず社内の方が誰でも入れるWorkspaceを用意しています。このWorkspaceに分析基盤を使っている方や使いたい方に入っていただいて、困ったらメンションしていただくようにしています。

DeNAはSlack Enterprise Gridを提供開始直後に導入しましたので、全従業員が社内のあらゆるWorkspaceに参加可能なSlackアカウントを持っています。実は南場さんのアカウントもあってですね、さすがにメンションしたことはないです。

この分析基盤専用のSlack Workspaceにはメンション先としてグループをつくっています。グループというのは、1つの名前に対して複数名を紐づけるようなSlackの仕組みです。わかりやすく@supportというグループを用意しています。

この@supportに私を含めたAI＆分析基盤と呼ばれるチームメンバーを紐づけています。なので、「@support 教えてください」みたいにメンションしてもらうと、私含めて数名に同時に通知が飛んできます。

実際の例です。スライド左上、かなりきれいな問い合わせの例ですね。「これこれこういうことをやってみたんですが、うまくBigQueryにロードされません」という。そして、その下の部分にログを貼ってくださっています。Slackだとこういうやりとりができるので、話が早いですね。

ちなみにこのケースは、Medjed（内製バルクローダー）のバグを踏んでいたので、この数十分後にバグフィックス版をリリースして解消しました。

右下のほうは、以前問い合わせていただいていた内容で、その後ステータスがわからなくなっていたので、「その後どうですか？」と聞いてみて、「問題ないです」と回答いただいたので、返事をしつつ、私たちの方でサポート用のIssueをクローズしました。

DeNAのAI基盤

ここまでで分析基盤についてお話しましたが、AI基盤についても紹介させてください。

DeNAのAI基盤では、AWS、GCPといったパブリッククラウド上で機械学習の基盤を提供しています。主なモチベーションは、GPUインスタンスを好きな時に必要なだけ使いたい、そして使わなくなったら落としてしまいたい、です。

クラウドですので、Infra as Codeが比較的容易に行えます。Terraformでインスタンスを立てるまでの部分をプロビジョニングして、インスタンス内のプロビジョニングは、ItamaeというRuby製のプロビジョニングツールを使っています。

AIのプロジェクトが発足しますと、今は最短で1週間ぐらいでインフラ提供を行えています。DeNA TechConというイベントで使った資料から1枚持ってきました。スライド左下部分が私たちですね。

図にX、Y、Zと書いた、AI技術を使うそれぞれのプロジェクトの、AI R＆Dエンジニア向けAWSアカウント、GCPプロジェクトを構築をします。その際、Infra as Codeのコード部分はGitHubに置いて、プロビジョニングはTerraformやItamaeで行っています。

分析基盤のクラウドネイティブ化が必要

ここまで今現在のDeNA分析基盤についてお話しさせていただきましたが、2020年代に向けてどうしていくか書いてみました。

分析基盤だけではなくAIの基盤についても合わせてご紹介させていただきたいのですが、これからのDeNAの分析基盤が目指す姿として3つキーワードを挙げました。「クラウドネイティブ」「分析基盤に留まらないAI＆分析基盤」「より安全な権限分離」の3つです。

まず「クラウドネイティブ」です。私たちはサービスを一般の方や企業さまに提供することがメインの会社ですので、サービスの提供も改善もスピードアップするためにクラウド化しています。それに合わせて分析基盤も、より一層クラウド化を推進していく必要があります。

とはいえ、例えばオンプレミスで提供しているAというサービスで、「Jenkinsを使ってください」「内製ダッシュボードのArgusを使ってください」と案内する一方で、AWSで提供しているBというサービスでは、「AWSのWebコンソールに入って、こういうふうにしてください」というような異なるオペレーションを推進してしまうと、横断的に分析を行っているアナリストの方にとってはサービス間での環境差異を理解して対応する手間が増えてしまいます。

ですので新しい仕組みを提供しつつも一定期間は、既存と同等のUXを提供し続けることも、同時に考え進めています。

AIと分析基盤を包括する

次に「分析基盤に留まらないAI＆分析基盤」と書きました。最初に自己紹介のところでもお話した、なぜAIと分析の間にアンパサンド（＆）が入るのかという話でもあります。分析の高度化とAI技術の導入が進んでくると、両者は必ずしも別物ではなくて、両方まかなえる便利な基盤とUXを提供する必要が生じてきます。

データ分析、AI、データサイエンス、また私たちは今Kaggleというデータサイエンス領域のコンペにとても力を入れています。そうすると、扱うデータが多様化します。そのような多様なデータをまかなえるような基盤が必要になってきています。

3つ目は「より安全な権限分離」です。扱うデータが多様化して、例えばこれまであまり考慮が必要なかった位置情報や、あるいは動画に一般の方が写り込んでいた場合どう扱うかといった課題がいろいろ出てきます。

そういう時、もともとAWSアカウントやGCPプロジェクトを分けてはいますが、さらに担保すべきデータの秘匿性に合わせて、より細かく分離するなどの対処を、必要に応じて行っています。

クラウドネイティブな分析基盤

いくつか例を紹介させていただきます。1つ目はクラウドネイティブな分析基盤の例として挙げさせていただきます。

オンプレミスで紹介した構成と比べると、データレイクまでクラウドで完結しています。この例に挙げたサービスでは、サービス自体のサーバーもクラウド上にありますので、あえてオンプレミスにデータレイクを持つ必要がないからです。

一方、アナリストの方が使うツールやUXは共通にしたいので、S3に蓄積されたログやスナップショットを、内製のバルクローダーMedjedで読み込んでBigQueryに送っています。これはMedjedに機能を追加することで実現しました。

BigQueryに入ってしまえば、これまでのオンプレミスでのサービスと同じArgus（ダッシュボード）から見れるようになります。アナリストの方はこれまでと同じUIやUXで分析が行えます。

次に、AI＆分析基盤として、SageMakerというマネージドサービスを組み込んだ例を紹介させてください。

Jupyter Notebookという、Web UIでPythonコードを書いて実行できるツールを使ったことがある方もおられると思います。このJupyter Notebookは非常に便利なんですが、セルフホスティングするといろいろな難点があります。そこで、Amazon SageMakerという、マネージドでJupyter Notebookを使えるサービスが提供されています。

既存のプロジェクトでは、AI R&Dエンジニア個々人がLinux VMにSSHログインしてJupyter Notebookを起動していたものを、SageMakerを導入してマネージドサービスで置き換えた例があります。

Jupyter Notebookの画面を簡単にご紹介しますと、このようにWeb UI上でPythonやShellを書けます。

SageMakerを使うと、AWSのコンソールにログインしていないとこの画面にたどり着けないという制御が入りますので、個々人がセルフホスティングするより安全に扱えます。

次にマルチメディアデータを扱うAI基盤の例を紹介させていただきます。諸事情で非常に概念的な図となります。

実案件のAI技術導入で、画像を扱うケースがとても増えています。いわゆるCV（Computer Vision）の分野です。CVの場合、アプリログやデータベースのスナップショットを収集していたこれまでのシステムとは色々と要件が変わってきます。データの種類も違えば、処理の粒度も違いますし、処理を始めるトリガーも変わってきます。

この例では動画がS3にアップロードされたら、Lambdaが動いて前処理的を行ったうえでSQSに通知する仕組みを導入しています。SQSの先をGPUインスタンスとつなげて、GPUインスタンス上でマシンラーニングの処理を行っています。