スタートアップでありがちな問題をAWSで解決する––認証基盤からログの扱い方まで

Startupのよくある課題をAWSで解決する

塚田朗弘氏（以下、塚田）：みなさん、こんにちは。「こんにちは」ですよね？　朝、藤倉（成太）さんが間違えて「こんばんは」と言っていましたが。よろしくお願いします。

今ご紹介があったとおり、このセッションは「[AWS Startup ゼミ] よくある課題を一気に解説！　～御社の技術レベルがアップする 2019 春期講習～」というかたちで、3名でお送りしていきたいと思います。

まず、3名がどういう人間かだけ、ちょっとお伝えしていきたいと思います。

私は塚田朗弘といいまして、スタートアップのお客さまを支援するソリューション アーキテクト……技術支援の担当者ですね。3人ともそうなのですが。そのなかでもモヒカンで、モバイルとかサーバレスとか、そういったテクノロジーを扱っている者になります。

よかったら、ここで祝福をしていただきたいのですが……今日は誕生日ということで（笑）。

（会場拍手）

塚田：ありがとうございます。こんな人間です。じゃあ、次どうぞ。

中武優樹氏（以下、中武）：同じく、スタートアップ ソリューション アーキテクトの中武と申します。

インターネット上では「Zabbio（ザビオ）」と呼ばれていまして。「Zabbix」というオープンソースのコミッターとかをやっていて、「Zabbio」と言われています。好きなサービス・技術領域は、ブロックチェーンとかデータベースがけっこう好きで、いろいろやらせていただいております。よろしくお願いいたします。

（会場拍手）

塚田：じゃあ、松田さんどうぞ。

松田和樹氏（以下、松田）：同じく、スタートアップ ソリューション アーキテクトの松田と申します。

よく「外国人は『Kazuki』も『Matsuda』も発音できないので、『Mats』と呼んでくれ」って話をしてるのですが、意外とAmazonの外国人の方は日本人に慣れていて、よく「Kazuki」と普通に呼ばれちゃうのですが、インターネット上だと「Mats」というアカウントで活動しています。

得意領域としては、ビッグデータやコンテナといった技術領域を主に担当させていただいております。よろしくお願いいたします。

（会場拍手）

AWS Start-up ゼミ よくある課題シリーズの概要

塚田：よろしくお願いします。こういった3人で始めていきたいと思います。では、本編に入っていきます。この「AWS Start-up ゼミ よくある課題シリーズ」はどういうものかを最初にお伝えします。

今の3人をはじめとして、AWSのスタートアップ ソリューション アーキテクトのチームは、年間で非常に多くのお問い合わせやご相談をいただいています。先ほども幕間の動画で、delyの大竹（雅登）CTOから「AWSの担当者のサポートが……」というお話をしていただいていましたが、「こういうものをやりたい」という年間数百件のご相談に、技術的にお応えしているわけです。

それをやっているなかで、みなさんが共通して悩まれる、よくある課題が見えてくるわけですね。「今のスタートアップシーンで、みなさんがこういう課題をお持ちなんだ」というのをまとめているものが、このシリーズになります。

この資料・セッション自体ですべてを詳細に解説するというよりは、「こういう課題がある」「こういうことをしたい」というユースケースに対して、「こういう筋道で考えたらいいんじゃないでしょうか？」という解決までの考え方と、その後見るべき資料などを示したい、というのがこのシリーズですね。

なので、このあとに具体的な内容に入っていくと、「思考フロー」という言葉が出てくるのですが、「こういう考え方でいったらどうでしょうか？」というのをまとめてあります。

「シリーズ」と言っているのですが、これまで「2017 夏期講習」から始まって「2018 春期講習」「2018 秋期講習」と、いろいろ出してきました。それぞれスライドが公開されているので、ぜひそちらを見てみてください。

今日は具体的にどういう話をしようと思っているかというと、こんな感じです。

これらが2019年の春時点で、我々3人がよくご相談をいただいているトピックですね。

「データストアの選び方」とか「認証基盤の作り方」とか。ログをちゃんと扱うために、「そもそも、ログってどうやったらいいの？」とか。「情シス（担当がいないがちゃんとしたい）」の話や、ちょっとビジネス寄りの「アクティブユーザを増やす」話とかですね。このあたりを、今日はお伝えしていきたいと思います。

データストア、どれを使えばいいのかわからない

じゃあ、最初にこのトピックからです。では、Zabbioさんよろしくお願いします。

中武：私からお話しさせていただきます、よろしくお願いいたします。「データストア、どれを使えばいいのかわからない」というお話です。

「データストアはどれがいいのか、どれを使っていいのかわからない」って、すごくいろんな方からよくいただく課題です。「AWSが提供しているデートストアサービスのうち、どれを使っていけばいいのかわからない」。あとは、「とりあえずRDBMSにデータを入れて置いて入れっぱなしにしているんだが、ここからどう移行していけばいいかがわからない」。また、「サービスがスケールしまくっていて、RDBMSだけでやるのはつらい」というような課題をよくいただいています。

「本当にしたいことは何か？」というと、「ワークロードに適したデータストアを選択したい」、あとは「そういうデータストアに（いい感じに）移行したい」ということですね。

思考フローとして、3つのステップを挙げています。1つ目は「マネージドサービスを使おう」、2つ目は「それぞれのデータストアの特性を知ろう」。最後に、移行の際には「ちゃんと検証しよう」というところですね。

データストアを変えるきっかけって、みなさんもスタートアップをやられているといろいろあると思うんです。開発しているうちに当初と仕様が急に変わっていって、RDBMSでやり続けるのがけっこうつらくなるケースがあると思います。

これは一例なのですが、ユーザーのアクションを都度保存しないといけなくなったとか、誰かのクリックアクションを常にDBへ書き出すような処理が必要になった場合とかですね。また、時系列データを扱う必要が出た場合とか。あと、急にチャット機能が追加になって、その全チャット履歴を保存したいみたいな。そういう仕様がいきなり追加されるケースもあるかと思います。

マネージドサービスを使う

中武：最初に挙げた思考フローの中で「マネージドサービス使おう」というお話をさせていただいたのですが、今のマネージドサービスを自分たちで手組みでやろうとすると、かなりコストがかかると思います。冗長化の仕組みやバックアップの仕組みを自分たちでやるのは大変なので、そういう複雑な作業は、できるだけマネージドサービスを使ってオフロードしていこうという話です。

とはいえマネージドサービスでできないことを自前のオンプレの環境やAmazon EC2とかでやられるケースもあると思うのですが、「本当に手組みでする必要性があるか？」の要件を確認していただければいいかと思います。

データストアの特性を知る

中武：データストアの特性を知ろうということで、データストアのカテゴリとユースケースをいくつか記載した図がこちらになります。

例えばKey-valueだと、Real-timeの入札のものやshopping cartとかで、Key-valueのデータストアがよく使われます。In-memoryだと、Leaderboardsとかキャッシュ用途で使われるケースが非常に多いです。

それに相関したマネージドサービスが、こちらのものになります。

なので、みなさまがよく使われているサービスとこういう図を見ながら、自分のワークロード・ユースケースに適したデータストアを一度振り返っていただけるといいかと思います。

データストアの移行方法です。

同じエンジンだったら、データをダンプしてインポートするやり方はわりと手軽にできると思うのですが、違うデータストアエンジンに変えたいとなってくると、変換の処理とかがすごく複雑になりがちなので、こういうDMS（AWS Database Migration Service）というサービスを使って対応することもできます。

例えば、Amazon RDSからAmazon Redshiftに持っていったりとか。そういう変換処理を、このDMSがやってくれますので、こういうものを活用していただけるのがいいかと思います。ただ、いくつか制限事項がありますので、そちらはドキュメントをいったん確認していただければよろしいかと思います。

ちゃんと検証する

中武：最後ですね。「ちゃんと検証しよう」というところで、適切なインスタンスタイプを選択する上で、検証はどうしても必要になります。負荷エミュレーションを使っていって、実際にどのぐらいのパフォーマンスが出るのかをきちんと確認していただく必要があると思います。

これはMySQLの例なのですが。書いてみて、どれぐらいの接続数で、書き込みなのか・読み込みなのかを選択して、負荷を測っている。

CloudWatchのメトリクスを見ながら、CPUはどこで頭打ちするのかとか。あとは、エラーログですね。スロークエリみたいなものを確認しながら。最後は、AWSのマネジメントコンソールにPerformance Insightsという画面がありまして、どのクエリがどれぐらいのCPUを使っているかみたいなものが、ある程度グラフィカルに見えますので、こういうものを活用していただくのがよろしいかと思います。

こういう検証をすることで、現状を把握することがすごく大事だと思います。queryやindexのチューニングをして改修するやり方もありますし、アーキテクチャを変えるやり方もあると思います。

「どうすればいいの？」みたいな話が、よくあると思うんです。「クエリを直せばいいのか、そもそもアーキテクチャを変えればいいのか？」みたいなことに悩んだ場合は、我々SA（ソリューションアーキテクト）に、ぜひ一度相談していただければいいかと思います。我々は、データストアの移行手順の提案とかもやっていますので、お気軽にご相談いただければと思います。

データストアの参考資料は、こちらになっております。

この資料は後ほど共有させていただきますので、ご確認いただければと思います。

塚田：今日はこんな感じで1トピックずつ進むのですが、コンパクトに1個5〜8分ぐらいで、一つひとつの考え方は今みたいなフローでざっくりやっていただいて。そのあとは、各トピックの詳細解説資料を見ていただければと思います。

我々はすごくたくさん資料を出しています。例えば「AWS Black Belt Online Seminar」とありますが、我々ソリューションアーキテクトやテクニカルメンバーが、週に2回無料のオンラインセミナーをやっているんですね。それが今、200近くの資料がトピックごとに全部まとまっています。こちらに詳しい解説があるので、それをぜひ見ていただきたいです。

この資料はSlideShareで公開される予定です。そうなると参考文献のリンクもクリックできるはずなので、ぜひそっちで見ていただきたいと思います。

……といったフォーマットで、次のトピックに進んでいきます。Zabbioさんよろしくお願いします。

認証基盤をちゃんとしたい

中武：次は、「認証基盤をちゃんとしたい」というお話ですね。

認証基盤をちゃんとしたいという話でよくいただく課題が、「サービスが増えてきたので、認証基盤を全部統一させたい」「ID／Passwordを使っているし、SNSを使っているし」みたいに認証が複雑になっているので、その基盤を全部統一したいというケースです。さらにいろいろな認証を使いたいと。

「本当にしたいことは何？」というと、「認証に柔軟性を持たせたい」とか、「認証サーバを自分たちで持ちたくない」というケースがあります。

思考フローとしては、まずAWSで提供している「Amazon Cognito」というサービスがありますので、それを使っていきましょうという話です。次に、Cognito の標準機能だけで実現できない要件があったら、AWS Lambdaトリガー機能を使ってカスタマイズすることもできます。最後に、「既存の認証サーバやサービスから、どうやって移行するの？」。この3つの思考フローをもとに、お話しさせていただければと思います。

まず、「認証どうしようか？」という話です。

これは一例なのですが、サービスを作る上で要件を決めると、「セキュアなシステムを作るから、ID／Passwordも全部暗号化してほしいし、SNS認証もしたいし、それからADとも連携したいよね」みたいなケースがあって。

開発者視点から言ったら、ID／Passwordを保管するためにわざわざサーバを立てたくないし、そもそも認証を実装するのが手間だし、なによりやっぱり認証情報を自分たちで持ちたくないケースがあると思います。

複雑な要件はAWS Lambdaでカスタム

中武：そもそも一般的にどういう認証が必要なのかというと、参考情報になりますが、このNISTという研究機関が出している報告書みたいなものがありまして。

それに、今の技術的動向を踏まえた上で、どういうパスワードの設定をやったほうがいいかが記載されていますので、こういうものをエッセンスとして参照していただけるといいかと思います。

話に戻ります。じゃあ、Cognitoを使っていこうという話ですね。

クライアント……Webでもモバイルでもいいのですが、Cognitoに対して「Authorize Get Token」すると、Cognitoがその先のSNSやOIDC（OpenID Connect）やSAMLとフェデレーションを行ってくれますので、Cognitoを使って認証実装が軽減されると思います。それで認証実装をやりたい場合は、こういうかたちでCognitoを使っていただくとAWS側にオフロードすることができるので、よろしいかと思います。

次に「複雑な要件があったらLambdaでカスタムしよう」というところで、ここではNo Password認証の仕組みを例に挙げて解説していきます。

まずクライアントからCognitoに問い合わせをして、「Define Auth Challenge」のLambdaに認証チャレンジのリクエストを投げます。そのあとに、一番下の「Create Auth Challenge」のLambdaが秘密のログインコードを生成して、Amazon SESでクライアントにメールを出します。

メールを受け取ったユーザーユーザーは、そのログインコードを見て認証ログインコードを打ち込むと、「Verify Auth Challenge Repsonse」のLambdaでそれが正しいかどうか検証できます。その結果「認証が通ったよ」とLambdaから返せば「次からの認証、つまりパスワードはもうチェックしなくていいよね」みたいなかたちの認証が、これで実現できます。

このLambdaファンクションのサンプルもGitHubで提供されておりますので、こういうものを使っていただくと、より柔軟性が高い認証ができます。たとえばLambdaを使った合言葉認証もできます。

最後に、既存の認証サービスから移行する場合ですね。

1番のID/Passwordの認証なのですが。Cognitoで ID/Passwordの認証を試みて、もし該当するユーザーが見つからない場合と、ユーザー移行Lambdaトリガーが設定されているとそのID/PasswordをパラメータにLambdaファンクションが起動されます。

そのLambdaから既存の認証サーバに対して、渡されたID/Passwordでログインを試みます。それが成功したらその旨をLambda関数の返り値として返せば、User PoolにUserが作成されるといったものになっております。こういうものを活用していただくと、ユーザ情報の移行がシームレスにできるかなと思います。

CSVでのインポートも対応しているのですが、その場合は全ユーザさんでPasswordの再設定が必要になってきますので、そこだけご留意いただければいいかと思います。

Cognitoの参考資料はこちらに載っていますので、興味のある方は、このあとぜひご覧いただければと思います。以上です。

ログをちゃんと扱いたい

松田：ここからは、私からお話しさせていただきます。3つ目のトピックは、「ログをちゃんと扱いたい」というところです。

何社かのスタートアップのお客さまからよくある質問の中で、「ログを取ってはいるけれど、傾向分析とかをぜんぜんやっていないので、どう使っていいかわからない」「そもそもログを取っていないのですが、どうしたらいいですか？」みたいな話がけっこう多いんですね。

そういう質問をいただくのですが、実際のところログを取るのって純粋な作業であって。「本当にやりたいことって何だろう？」と考えると、「そのログを使って、サービスの状況の把握したい」とか「仮説検証サイクルを回すためのKPIを取得したい」、あるいは「大量にたまったログから得られる情報を、ビジネスに活かしたい」。最近ですと、マシンラーニングやAIの文脈でイメージしていただくといいかなと思います。そういったことが、本当にしたいことなんじゃないかなと思っております。

このあと順に解説していくのですが、思考フローとしては、まず（生ログを）Amazon S3に貯めていきましょうという話、次に必要があれば加工していただいて、最後にS3を起点に活用していきましょうという話をさせていただきます。

本題に入る前に、AWSでよくお話しさせていただいているものに、まずData Lakeという考え方がございます。

Data Lakeとはなにかというと、定義がいくつかあるのですが、多種多様なデータを一元的に保存できて、かつ、そのデータが失われない。そして。無制限にデータが入るんですね。サイズ制限がなくて、どんどん入れていくことができる。

そして、入れるだけではなくて、データに対して決められた方法（で、すぐにアクセスできる）。ここで言う「決められた方法」とはシステムの話なのでAPIになります。定められたAPIで、すぐにアクセスして取得できるということもData Lakeの定義に含まれます。

ここで言うデータは、ログデータに限らず、センサーデータですね。いわゆる移動体……モバイルであるとか、最近ですとモビリティですね。自動車からの位置情報とか。あるいは、工場などに設置している温度や気圧といったセンサーデータも含みますし、データベースで保存しているデータもそうですね。あるいは、純粋なテキストデータかもしれません。

そういったものを一元的にData Lakeに入れて、そしてAPIによって呼び出しましょうというのがData Lakeの考え方になります。

AWSでData Lakeとして使われる代表的なサービスは、Amazon S3になります。Amazon S3は、もうすでにお使いのお客さまもいると思うのですが、データのバックアップ用途で使われているケースなどもあると思います。実際はもちろんデータのバックアップだけではなく、例えばアナリティクスツールやマシンラーニングサービスなど、AWSの様々なサービスと連携することができるんです。

なので、基本的には「S3を中心に、どんどん考えていきましょう」というのが、AWSでの考え方になります。

生ログはS3に貯める

松田：ここからは、「じゃあ、どうやってS3にログを貯めていけばいいんだ？」というお話です。

まず、例えば、Amazon API GatewayやAWS LambdaやAmazon RDSみたいなマネージドサービスは、デフォルトでAmazon CloudWatchにログを出力するような設定が入っております。

なので、それに対しては、CloudWatchもAWSでいろんなサービスと連携できます。例えば、Amazon KinesisのData Firehoseというサービスがあり、そちらを経由してS3に出力することができるので、こういったマネージドサービスのログをS3に貯めることもできます。

また、スタートアップだと、最近はコンテナを使って開発されているお客さまが多いかと思いますが、Dockerコンテナについては標準でロギングドライバという仕組みがあって、その中でawslogsというものをお使いいただくと、直接CloudWatchにログを飛ばすことができるようになっております。

また、コンテナではなくて、EC2仮想マシンから直接CloudWatchにログを送ることもできます。これはオープンソースのソフトウェアを使っていただいても、AWSが提供しているKinesisやCloudWatchのエージェントをお使いいただいてもかまいません。送るログデータは、例えばエラーログ・アクセスログ・アプリケーションが吐いているログとか、なんでもかまいません。

とはいえ、CloudWatchで可視化したりとか、リアルタイムに見たりしたいログばかりではないと思うんですね。Apacheのアクセスログとかを1行1行見ても、あんまりうれしいことはないと思っていて。

「貯められばOK、見る必要はない」みたいなログに関しては、直接Kinesisに流すことによって、S3には貯まるけれどビジュアライズはしない。CloudWatchでビジュアライズしないから課金が抑えられます、みたいな使い方もできます。

また、サーバサイドにかかわらず、クライアントサイドですね。JavaScriptで構成されているブラウザのフロントエンドであるとか、モバイルアプリケーションからSDK経由で直接Kinesisにイベントデータ・ログデータを送ることも可能ですので、場合によってはこういった手法をお使いいただいてもいいかもしれません。実際にそういうお客さまもいらっしゃいます。

また、AWSはどんどんサービスが増えていくのですが、サービスの中にはKinesisに対して直接サービス間連携でイベントを出力できるものがあります（Amazon Pinpoint や AWS IoT等）。こういったものは、ほぼ開発に一切手を入れずに、ボタンのスイッチを入れていただくだけで出力できるものもございます。

あとはKinesis経由ではなくて、Amazon CloudFrontやELBなどは直接S3にログを出力できる機能がございますので、これがそのままS3に吐かれる。そういったものもございます。

とはいえ、すべてのお客さまがマネージドサービスを現在使っているかというと、そんなことはないかなと思っていまして。自社のMySQLでもPostgreSQLでもいいのですが、すでにデータベースにログを貯めてしまっているお客さまもいると思うんです。

そういったお客さまについては、AWSでDatabase Migration Serviceというサービスを提供しております。こちらをお使いいただくと、例えば「1日1回や週1回など、定期的にS3へ出力します」みたいなものも簡単に、さらによりニアリアルタイムに組むことができるので、のちのち移行していただいたほうがいいかなとは思うのですが、取り急ぎS3に貯めて同じワークフローに乗せることは可能となっております。

迷ったらKinesis Data Firehoseを経由する

松田：S3の話をしたときに、「Kinesis Data Firehoseってすごく出てくるな」と思われている方がいらっしゃるかなと思うのですが、Kinesis Data Firehoseは便利なので、ぜひお使いいただければいいかなと思います。

理由としては、S3に保存する際の、いろいろな考慮事項を吸収してくれるところがあります。例えば、ストリーミングで流れてくるデータを1行1行S3にファイルで保存されると、もうファイルがどんどん増えてたまったもんじゃないということがあると思います。しかし、間にKinesis Data Firehoseを挟んでいただくと、ストリーミングデータをバッファリングしたり圧縮したりしてくれるので、便利です。これはデータを活用する際のスピードやコストにも影響してくるので、のちのち重要になってきます。

また、場合によっては「フォーマットを変換したい」ということがあると思うんですよね。そういった場合もFirehoseの中からLambdaを呼んで、そのLambdaの中で書かれたコードによってデータのフォーマットを変更することも可能となっております。

また、これはちょっと発展形なのですが、将来的にスタートアップでビジネスのやり方や分析手法が変わるとかでS3以外のサービスを使いたい場合にも、Firehoseの設定を変更していただくだけで、例えばRedshiftやAmazon Elasticsearch Serviceみたいなサービスもご利用いただけるようになります。

あと、これはまだ東京にはきていない（注1：）のですが、「Kinesis Analytics」というKinesisに貯まっているストリーミングデータを直接分析するサービスも使えるので、将来的な拡張性の面でも挟んでいただくことが、非常に有用かなと思います。

（注1：2019/5/8、Amazon Kinesis Data Analytics は東京リージョンで利用可能になりました）

そのままで使えないなら加工する

松田：次に、「加工しましょう」みたいなフローです。

ここでお話しするのは、あくまで一例です。ELBから流れてくるS3に貯まるログデータはCSV形式で保存されるのですが、場合によってはCSVではなく、別のフォーマットに変更したいことがあると思います。

そういった場合に、ここの一例では「AWS Glueというサービスをお使いいただくといいんじゃないかな」と書いてあるのですが、それを噛ませてフォーマットとファイル形式を変更しましょう、みたいなものも提案しています。

変更したあとで場合によっては、フォーマットの変更だけではなく、日次で集計したいケースもあると思います。「これは、直接やっちゃダメなんですか？」というお話もあるかと思います。変換のフローが決まっていれば、フォーマットを変更するところで一緒にやってしまってもいいと思うのですが。

例えば、これを多段にしておくと、日次集計のあとに週次集計と月次集計も含めた3つをやりたいとなったら、途中から分岐したほうがフォーマットの変換が1回で済みますよね。そのような話もあるので、どちらがいいかはワークロードによりますというのが、正直なところです。

また、構造化されていないデータも、Firehoseでデータを保存しているケースもあるかもしれませんね。テキストデータなどです。そういったものについては、例えば、「いったんS3で受けたあとに、非構造化のデータを構造化するように変換しましょう」とか「もしかしたら破損しているレコードがあるかもしれないので、そういったレコードを削除しましょう」みたいなものをやっていただくのも、いいかなと思います。

場合によっては、このロードバランサーから流れてくるデータとアプリケーションから流れてくるデータをくっつけて、新しいデータを生成して、「これを使ってビジュアライズしましょう」とか「ダッシュボードを作りましょう」みたいな話もあると思います。これは、いわゆる「変換して使うと便利になりますよね」みたいなお話ですね。

上の2つはログのお話なのですが、場合によっては、ログデータではなくマスターデータですね、アプリケーションの会員情報などのマスターデータが、RDSに貯まっていることがあると思います。そういったものについても、S3に出力しておく。

例えば、もうちょっと頻繁に変わるものでもいいかなと思いますが、マスターデータを日次で抽出して、場合によっては個人情報が含まれている可能性があるので、マスキングしてS3に出力しましょうと。

そうすると、個人情報がマスクされたマスターデータがS3で使える状態になります。そちらと、過去に集計した日次でサマったデータをくっつけることによってリッチ化されたデータができます。そうすると、またこれを使ってダッシュボードを作るなどで活用できるようになるので。あくまで一例ではあるのですが、こういったいろいろなフローを辿って活用の幅を広げることが可能です。

S3を起点に活用する

松田：「S3を起点に活用していこう！」です。

まずよくあるのは、「貯まったデータが大きいので、ビッグデータの分析をしたい」ということに関しては、AWSはS3に対して直接SQL文で分析をやるとか、クエリを投げられるサービスがいくつかあります。例えば、Amazon AthenaとかRedshift、あるいはElastic MapReduce（Amazon EMR）ですね。こういったサービスをお使いいただくことができます。

クエリを書けるだけではなく、これらのサービスにBIツール・ダッシュボードサービスをくっつけることによって可視化して、見やすくユーザに示唆を提供することもできます。AWSでもAmazon QuickSightというダッシュボードサービスをご提供していますし、オープンソースのものもいくつか出ているので、自社のワークロードに合うものをご選択されるといいかなと思います。

また、ダッシュボードで示唆を得るだけではなく、自分自身でクエリを書きたいケースがあると思います。そういった場合も、ユーザ自身が直接これらのサービスに対してクエリを投げてご利用いただくことも可能ですので、そういった感じでデータ分析をやっていただくといいのかなと思います。

また、最近流行りの機械学習についても、AWSは多種多様なサービスを提供しています。ほぼすべてのサービスがデータソースとしてS3を参照して、そのS3のデータをもとにモデルを生成したり推論結果を返したりするように作られているので、そういった場合もS3にデータが貯まっていると非常に便利かなと思います。

あとは、リアルタイム分析ですね。先ほど「Kinesis Firehoseを間に挟んでいると、途中で分岐できる」というお話がありました。例えばS3ではなく、途中でElasticsearchに流す。Elasticsearchだと一緒についているダッシュボードサービスでKibanaというものがお使いいただけるので、Kibana経由でリアルタイムで分析とかもできますし、先ほど少しお話ししたKinesis Data Analyticsというサービスをお使いいただいて、リアルタイムに分析をしていくことも可能になっております。

私の、ログの分析の話は以上になります。

実装時の参考資料としては、こんな感じです。

去年の「AWS Summit 2018」ではけっこうData Lake系のサービスの事例が多く出ているので、非常に参考になるんじゃないかと思います。この（スライドの真ん中）あたりですね。後ほど見ていただければと思います。