【開催報告】Amazon Redshift事例祭り（活用編）～This is our “Reborn Redshift.”

こんにちは。アマゾンウェブサービスジャパン株式会社パートナーソリューションアーキテクトの大林です。

8 月 6 日に、「Amazon Redshift事例祭り（活用編）～This is our “Reborn Redshift.”」を開催しました。
Amazon Redshift は過去 18 ヶ月で 200 以上のアップデートを重ねており、常に進化を続けております。本イベントでは、Amazon Redshift の最新テクノロジーを現場のビジネスでどう活用できるのかについて、4 社のお客様より、実際の事例に基づいて、本音を交えながらお話いただきました。また、AWS ソリューションアーキテクトより、Amazon Redshift の最新情報の解説や、最新機能に関するデモンストレーションをライブで実演しました。

Amazon Redshift 最前線 ~Dive Deep & Update~ [slides]

大薗純平
アマゾンウェブサービスジャパン株式会社ソリューションアーキテクト

大薗からは、Amazon Redshift の最新情報について、「Performance & Scalability」、「Data lake & AWS integration, in-built analytics」、「Fully managed, secure & cost-effective」という 3 つの観点から解説を行いました。

「Performance & Scalability」の観点では、次世代 Redshift インスタンスである RA3 インスタンスについて説明を行いました。RA3 インスタンスでは、コンピューティングとストレージが別々にスケールし、また、別々に課金されます。実データは、Amazon S3 に格納されますが、直近のアクセスデータは、各コンピュートノード上の SSD にキャッシュされます。RA3 インスタンスは、従来の HDD ベースの DS2 インスタンスと比較すると、最大 2 倍のパフォーマンスと 2 倍のストレージ容量となり、また、従来の SSD ベースの DC2 インスタンスと比較すると、8 倍以上のストレージ容量となります。DS2 インスタンスや DC2 インスタンスから RA3 インスタンスに移行しても、完全な互換性が保たれるため、アプリケーションへの影響はありません。RA3 インスタンスには、ra3.16xlarge と ra3.4xlarge という 2 種類のインスタンスタイプがあり、そのスペックの詳細や、既存クラスターからの移行目安のマトリクスについて紹介しました。ただし、こちらの内容はあくまでも目安であり、実際に移行される際は、実際のワークロードやクエリの内容に基づいた検証を事前に実施いただくことを推奨するということを強調しました。また、8 月 6 日時点プレビュー中で、RA3 インスタンス向けの新機能である AQUA（Advanced Query Accelerator）についても紹介を行いました。RA3 インスタンスは、コンピュートノードとマネージドストレージの間が広帯域ネットワークで接続されていますが、クエリの内容によってはネットワークボトルネックが発生する可能性があります。コンピュートノードとマネージドストレージの間に AQUA ノードが入ることにより、ボトルネックを解消し、処理の高速化が図れることを解説しました。また、高い圧縮率と性能を実現する新たな列エンコーディングタイプである AZ64、頻繁に実行されるクエリパターンを事前に計算しておくことでクエリの高速化を図るマテリアライズドビュー、同時実行が増加した時も、処理能力を柔軟にスケールできる Concurrency Scaling の説明も実施しました。

続いて、「Data lake & AWS integration, in-built analytics」の観点で、解説を行いました。まずはじめに、DWH とデータレイクをデータがニーズに応じて相互に循環することにより、あらゆるデータを分析することが可能になるという観点で、Amazon Redshift によるレイクハウスアプローチという考え方について紹介しました。レイクハウスアプローチに関わってくる主要な機能であるデータレイクエクスポート、つまり、Apache Parquet 形式での UNLOAD コマンドによるエクスポート機能や、Amazon Redshift 上から、Amazon S3 上のデータを直接読み込むことができる機能である Amazon Redshift Spectrum 用の外部テーブルに対して、Amazon Redshift 上のローカルテーブルからCTAS（CREATE TABLE AS SELECT）や INSERT INTO によるデータの追記を行えることを解説しました。また、Amazon Redshift 上のローカルテーブルと Amazon Redshift Spectrum の外部テーブルの結合処理において、2倍程度の性能改善が行われたこと、AWS Lake Formation と Amazon Redshift を連携することで、権限管理の一元化が可能であること、空間関数のサポート、DWH に連携する前の OLTP 上の最新のデータを Amazon Redshift 上から見ることができるフェデレーテッドクエリについて説明を行いました。

3 つ目は、「Fully managed, secure & cost-effective」という観点で、ビジネスの優先度に応じて、クエリに優先度をつけることができる自動 WLM（Work Load Management：ワークロード管理）、列レベルのアクセルコントロールへの対応や、テーブルメンテナンス周りのエンハンス、つまり、統計情報更新や Vacuum（データの再編成処理）などの処理が自動化されていて、機械学習を活用して、負荷が低いタイミングで処理が自動実行されることを説明しました。また、Amazon Redshift でのテーブル設計のポイントとなる分散キーやソートキーに関して、Amazon Redshift Advisor の機能が変更内容をリコメンドしてくれ、変更するための実際の SQL コマンドも案内してくれるため、一から設計しなくても良いということを紹介しました。

最後に、ここまで話してきた内容を総括し、本セッションを締めくくりました。

ソーシャルゲームの膨大なログを扱うCygamesのAmazon Redshift活用事例 [slides]

藤田晋哉様
株式会社Cygames データ分析基盤チーム

Cygames 社は、「最高のコンテンツを作る会社」ということをビジョンとして掲げられており、運営ゲームタイトルとしては、グランブルーファンタジー、神撃のバハムート、WORLD FLIPPER などがあげられます。同社藤田様からは、Cygames 社のデータ分析基盤についてご紹介いただき、最近リリースされた Amazon Redshift の機能を適用された事例や、知見についてご説明いただきました。

Cygames 社では、ゲームにおいてのデータ分析、例えば、ユーザーがアイテムを取得したなどのログを Amazon Redshift に入れてその内容について分析し、次の施策に生かすということを実施されており、そのための基盤として Amazon Redshift を採用され、その運用を藤田様のチームで実施されています。Cygames 社の分析基盤としては、Amazon Redshift を採用される前は、オンプレミスの DWH からタイトルごとに段階的に Amazon Redshift に移行され、2018 年 4 月頃に Amazon Redshift へ完全に移行を完了されたそうです。主に、ds2.xlarge インスタンスを利用いただいており、タイトルごとに 2 〜 16 ノードの構成で、合計 15 クラスターで運用されています。

分析基盤の構成としては、ゲームのデータベースからログデータを取得したり、Amazon EC2 上のゲームサーバーからアクセスログを取得し、Amazon S3 にデータを取り込み、Amazon S3 から COPY コマンドで Amazon Redshift に取り込むという構成になっています。Amazon Redshift に取り込まれたデータは、大きく 3 つの用途で使用されているとのことでした。1 つ目は、分析部隊によるユーザーの行動ログ分析などの実施、2 つ目は、内製 BI ツールでの使用、最後に 3 つ目として、不具合調査などでゲーム DB に直接クエリを実行すると応答がなかなか返ってこないようなケースで Amazon Redshift を使用する場合があるというお話でした。

Cygames 社の分析基盤における大きな課題として、データ容量の問題がありました。データレイクとして使用していた Amazon S3 の総容量は 2.4PB ありました。理由としては、ゲームのステータス情報などを管理する関係で「横に長い」レコードが多いこと、ゲーム内のイベントなどで周回数を重ねることで報酬がもらえるものが多いためレコード数も増えやすいこと、データ保持期間も一番長く運用しているタイトルで 9 年程度であることがあげられ、ある程度古いデータは一括でアーカイブするなどして、現在は 1.5PB に抑えられているというお話でした。

データ量が多いということから、Amazon Redshift に入れるデータはなるべく直近のものに絞り、古くなったレコードを削除して容量を空ける作業を大体毎日いずれかのクラスターで実施されていた状況の中、容量が大きくなりやすいテーブルは Amazon Redshift Spectrum を活用することで、Amazon Redshift のディスク容量を節約されることにしたそうです。例として、Amazon Redshift 上に保持していた、ユーザーの成長度合いなどを分析するために作成する時系列のテーブルを Amazon Redshift Spectrum に移行された例をあげられておりました。当初、Amazon S3 上にあるデータは CSV 形式で、また、日付でパーティションできるようなデータ配置となっておらず、Amazon Redshift Spectrum で利用しづらいデータ形式であったため、前処理として Amazon EC2 上でバッチ処理をさせて Apache Parquet 形式への変換と Amazon S3 内へのデータの再配置をされて運用されていたというお話でした。

続いて、Amazon Redshift のデータレイクエクスポート機能の活用例についてお話いただきました。Cygames 社では、Amazon EC2 上で CSV 形式から Apache Parquet 形式への変換処理、また、Amazon S3 内への再配置を行なっておりましたが、Amazon Redshift の UNLOAD コマンドに置き換えることにされたそうです。その結果、データの変換処理速度が大幅に改善し、例えば、もともと変換処理に 450 分程度かかっていた処理が、60 分程度で完了するようになったそうです。一方で、圧縮効率は落ちたというお話でしたが、Amazon S3 上のサイズのためそれほど気にならないというお話でした。

最後に、RA3 タイプのインスタンスへ移行された事例についてお話いただきました。Amazon Redshift Spectrum である程度容量が節約できても、容量が課題となるタイトルも存在していたという背景から、RA3 インスタンスの導入を検討されたそうです。タイトル毎に構成が異なるため、個別に検証を行われたというお話しでした。検証としては、RA3 インスタンスに移行しても普段の業務に支障が出ないこと、既存の構成と同じ費用になる構成であること、また、RA3 インスタンスに置き換えたとしても、クエリの処理速度やロード処理が遅くならないことが検証されたというお話でした。2つの検証結果についてお話いただきました。1 つ目は、現行は、ds2.xlarge の 8 ノード構成であり、移行後の構成として、ra3.4xlarge の 2 ノード構成のケースです。コストは、約 13％安くなる一方で、クエリの処理速度は全体的には速くなったもののものによっては遅くなったケースもあり、ロード処理については遅くなったというお話でした。2つ目の例としては、ds2.8xlarge の 6 ノード構成であったものを、ra3.4xlarge の 12 ノード構成へ移行するケースです。こちらも同様にコストは約 13％安くなり、また、分析クエリは全体的に速くなり、ロード処理はかなり速くなったというお話でした。2 つ目のクラスターについては、移行を実施されたそうです。実際に RA3 インスタンスへ移行された際の時間手順についてもお話いただきました。移行された結果として、2 〜 3 ヶ月くらいおきに特定のイベントが開催されるたびに、Amazon Redshift の容量削減処理を行われておりましたが、一気に容量に余裕ができ、またロード時間や分析クエリの処理時間も概ね事前検証の通りだったということです。現在は、もっとも大きい規模であるこの 1 クラスターのみ移行が完了されているというお話でしたが、徐々に他のクラスターも RA3 インスタンスに移行していきたいというお話でした。構成によっては、ロード処理や一部のクエリで処理時間が増えてしまう場合もあるため、事前検証を推奨するとのことでした。

最後に、ここまでお話いただいた内容を総括いただき、本セッションを締めくくられました。

RA3で実現するデータドリブンな文化 [slides]

小宮山紘平様
株式会社FiNC Technologies プラットフォーム本部運営推進部分析グループデータサイエンティスト

FiNC Technologies 社は、ヘルスケア全般を手がけられており、FiNC Ads や FiNC Plus などといった様々な有料サービスを提供されています。代表するアプリとして、FiNC アプリがあり、全ての人の健康な生活をサポートするという思想のもと、歩数や食事、体重、睡眠といったライフログを管理する機能、最新のヘルスケアを情報を提供する機能を備えた総合的なヘルスケアアプリを提供されています。同社小宮山様より、FiNC Technologies 社が、AWS を活用してデータドリブンな文化を作っている方法と、その中で、Amazon Redshift の RA3 インスタンスがどのような役割を担っているかを実例を交えながらご紹介いただきました。

まず、データドリブンな文化を作るためにデータ基盤に求められる条件として、3 点挙げられました。「データが一箇所に集約されていること」「データが活用できる形になっていること」「データを全ての社員が利用できるようになっていること」です。「データが一箇所に集約されていること」という観点では、FiNC データ基盤は、データレイクと DWH を Amazon Redshift 上で実現されており、DWH 化したデータを BI ツールから参照したり、Amazon SageMaker や Amazon Personalize を用いてデータ活用を実施したりされているそうです。Amazon RDS のデータやアプリの行動ログ、サーバーのログなどといったあらゆるデータ、つまり、FiNC アプリ内で発生するデータだけでなく、FiNCアプリにまつわるあらゆるデータが Amazon Redshift に集約されています。例えば、Amazon RDS のデータは AWS Database Migration Service（DMS）を使って Amazon Redshift に同期させていたり、アプリの行動ログは、アプリから、ストリーム形式で Amazon Kinesis Data Firehose に送られてきたものを Amazon S3 に転送し、Amazon Redshift に取り込むような形になっているそうです。また、API サーバーのアクセスログなどの情報は、Fluentd を経由して Amazon Redshift に収集されているそうです。外部データについても、Amazon API Gateway や Amazon Kinesis Data Firehose などをうまく組み合わせることにより、連携してデータを Amazon S3 経由で取り込んでいるというお話でした。基本的な考え方として、Amazon S3 にデータ取り込んで、Amazon Redshift に入れるという形式を取られているということで、Amazon S3 を介する形が良いというお話でした。

FiNC データ基盤では、一箇所に集約したデータを中間集計して、作りやすい形に加工しておくことで、DWH 化するということを行なっているそうです。これにより、都度生データを加工するための複雑な SQL を書く必要はなくなります。そのため、簡単な SQL や構文を理解すれば、誰でもデータが抽出できるようになるという考え方です。中間集計を行なっておくことで、膨大な生データに対して、都度クエリを発行する必要がなくなるため、クエリの実行時間を大幅に短縮できます。具体例として、中間集計の処理に1時間程度かかるものが挙げられていましたが、毎回1時間かかると誰も使わないようになってしまうことを避けられるというお話でした。

また、分析する人からわかりやすいようにデータが格納されているそうです。マスターデータやユーザーデータ、ログデータから抽出・加工した特定の行動ログを組み合わせることで、履歴データを作成し、ファネル分析やクロス集計をしやすいデータを加工しておき、履歴をさらに加工することで、KPI などのデータとしてあらかじめ集計されているというお話でした。履歴データの例として、プッシュ通知中間集計があげられ、プッシュ通知が効果的なプッシュ通知だったかどうかを複雑な SQL を書かずに、テーブルを参照するだけで情報を得ることができるように履歴データを保持されているそうです。中間集計のテーブルを機能に合わせて事前に設計しておくことで、各チームが専門的なスキルを要求されずにデータを参照したり活用したりする環境を作ることができるというお話でした。また、中間集計について、中間用の SQL を作成するだけで追加可能であると言う仕組みを作っているのが、FiNC のデータ基盤の大きな特徴と考えられているというお話でした。複雑な SQL を書く必要はあるため、全てのメンバーがこれができると言う状態にはならないが、特定のプログラミング言語で ETL 処理を書かなければいけないという状況よりはハードルが低くなっているというお話でした。実際に社内でこれらの中間集計の SQL を作成するメンバーは、エンジニアがバックグラウンドではないメンバーも多いとのお話でした。この取り組みにより、エンジニアのスキルを持つ専門のメンバーを雇う必要はなくなり、多くの人が対応できるようになっているというお話でした。

続いて、全ての社員が BI ツールを利用して、データを参照することができるというお話がありました。会社のアカウントを持っていれば誰でも利用可能で、Amazon Redshift に機密情報が入らないように徹底されているということでした。BI ツールで参照する以外にも別のツールでアクセスするケースもあるそうです。例えば、Amazon SageMaker を使って、複雑な統計処理や機械学習系のコードを書いてさらなる分析を行ったり、AWS Glue を経由して Amazon Personalize にデータを転送し、サービスの中にあるレコメンドシステムの最適化に利用するケースなどがあるそうです。ヘルスケア領域におけるデータの分析には、収集しているサンプル数が重要とのことで、FiNC アプリは、ヘルスケア領域では国内 No.1 のダウンロード数であり、それを生かして今後もさらなる活用を進めていきたいと考えていらっしゃるということでした。

ここまでは、「データが一箇所に集約されていること」「データが活用できる形になっていること」「データを全ての社員が利用できるようになっていること」の 3 点を FiNC データ基盤でどのように満たしているのかということについてお話いただきました。続いて、環境構築されるにあたって、Amazon Redshift が優れていた点についてお話いただきました。1 点目は、各種データの集約が簡単に構築できたということでした。Amazon RDS のデータを Amazon Redshift に同期するために AWS DMS を利用されており、使い勝手がとても良かったというお話でした。また、Amazon S3 を経由することで、あらゆるデータを Amazon Redshift に取り込むことができるということでした。2 点目として、更新系の SQL が実行できることがあげられました。様々な社員がデータを扱う中で、中間集計の追加や集計が活発に行われ、再集計がかなり頻繁に行われる環境であるそうです。また、サービスが日々開発されていく中でログの仕様も変わることがあるということで、データは更新されるものと言う前提で作られている Amazon Redshift とは相性が良かったというお話でした。3 点目として、更新系のクエリが実行できることも含めて、挙動が MySQL や PostgreSQL といった RDB と非常に近いということがあげられました。そのため、メンバーへの導入コストが低く、エンジニアにはほとんど教育が不要というお話でした。エンジニア以外にも一般的な RDB の教材を流用することで、こういうものだと教えやすいというお話でした。

また、Amazon Redshift の RA3 インスタンスによって改善した点についてもお話いただきました。RA3 インスタンスを採用される前に頻発していた問題として 2 点あったそうですが、いずれもストレージ関連のものだったそうです。1 点目は、クエリ実行時に起きるディスクフルの問題であり、重いクエリを実行すると非常に大きな一時テーブルが作成されて容量があふれて応答不能になる場合があるが、誰でもSQLを実行できる環境であることから、不慣れな社員によって重いクエリを実行されてしまうことが避けられなかったというお話でした。2 点目は、ストレージ容量がかなり小さいということでした。あまり参照しない過去データを保持するためにノードを増やす必要があったそうです。また、全期間のデータを保持していないと意味がないデータも存在し、過去データをどこに保持しているのかなどの管理も大変だったというお話でした。RA3 インスタンスを導入いただくことによりこれらの問題が解決され、クエリ実行時のディスクフルが発生することはなくなり、過去データも管理する必要なくなったということでした。

最後に、ここまでお話いただいた内容を総括いただき、データドリブンな文化を作る目的において、Amazon Redshift の RA3 インスタンスは非常に適したサービスであるというお話で、本セッションを締めくくられました。

実演 Amazon Redshift – 最新機能はこう使う [slides]

平間大輔
アマゾンウェブサービスジャパン株式会社ソリューションアーキテクト

平間からは、4 つのテーマで、デモンストレーションをライブで実演しました。

1 つ目は、「RA3 インスタンスの実力を探る」という題目で、デモンストレーションを実施しました。RA3 とは、第三世代の Amazon Redshift インスタンスであり、リーダーノード、コンピュートノード、マネージドストレージで構成されています。今回は、ds2.8xlarge インスタンス（4 ノード構成）、dc2.8xlarge インスタンス（4 ノード構成）、ra3.16xlarge インスタンス（2 ノード構成）というインスタンス乗り換え時に同程度の性能とされているサイズで、3 つのクラスターのタイプを準備し、2 つのクエリを実行させるというデモンストレーションを実施しました。具体的には、TPC-H のデータを 1TB 投入し、クエリを実行するというシナリオでデモンストレーションを行いました。RA3 クラスターについては、30TB の他のデータも投入されている状態で実行しました。TPC-H の 8 番のクエリと 3 番のクエリの実行を実施しましたが、8 番のクエリについては、ds2.8xlarge インスタンス（4ノード構成）と ra3.16xlarge インスタンス（2 ノード構成）で約 7 秒、dc2.8xlarge インスタンス（4 ノード構成）で約 6 秒という実行時間でした。3 番のクエリは、3 つのテーブルを結合する集計クエリで、8 番のクエリよりは少し時間がかかるクエリとなっていますが、ds2.8xlarge インスタンス（4 ノード構成）で約 23 秒、dc2.8xlarge インスタンス（4 ノード構成）で約 19 秒、ra3.16xlarge インスタンス（2 ノード構成）で約 18 秒という実行時間でした。実行クエリにより、インスタンスタイプごとに実行時間のばらつきがあるため、一概にどのインスタンスタイプが速いとすることが難しく、ワークロードによって異なってくるため、実際に実行されうるクエリで検証を実施いただいてから選択いただくのが良いというお話をさせていただきました。また、DC2 や DS2 から RA3 クラスターに移行する際の手順についても実際の画面を提示しながら説明を行いました。AWS マネージメントコンソール上で、Amazon Redshift ダッシュボードを開き、クラスターのメニューから DS2 のクラスターを選択し、アクションメニューから「サイズ変更」を選択し、「Elastic resize（デフォルト）」を選択いただいた上で、ノードの種類として、「ra3.16xlarge」を選択、ノード数を「2」と設定しインスタンスタイプを変更できることを説明しました。また、インスタンスタイプの変更については、スケジューリング実行も可能であることを補足しました。

2 つ目は、「Concurrency Scaling が効くとどうなるのか？」という題目で、デモンストレーションを実施しました。Concurrency Scaling は、メインクラスターでのクエリのキュー待ちが発生すると、バックグラウンドで別の独立したクラスターを自動拡張させ、並列実行度をあげる機能です。今回は、dc2.8xlarge インスタンス（2 ノード構成）のクラスターを 2 つ準備し、片方のクラスターのみ Concurrency Scaling を有効に設定し、その他の設定は両クラスターで統一させ、ベンチマークツールを使って、分析系のワークロードを 20 セッションから同時実行させるというシナリオでデモンストレーションを実施しました。AWS マネージメントコンソール上から、Concurrency Scaling に関する設定を行えることを実際の画面で説明しました。Concurrency Scaling を ON としていないクラスターについては、クエリのモニタリングを参照すると、11 クエリは実行中であるのに対し、9 クエリは待ち状態であることを確認しました。一方で、Concurrency Scaling を ON としているクラスターについては、クエリのモニタリングから、Concurrency Scaling はキュー待ちが発生すると追加のクラスターが立ち上がる動きであるため、最初はキュー待ちが発生していることを確認し、その後、追加で 2 つのクラスターが立ち上がり、待たされるクエリが減り、デモンストレーションのタイミングでは、17 クエリ実行中であることを AWS マネージメントコンソール上から確認しました。一連の解説が終了し、ベンチマークツールに戻ると、Concurrency Scaling を ON にしたクラスターは処理が全て終了しているのに対し、Concurrency Scaling を OFF にしたクラスターはほとんどの処理がまだ終わっていない状況であることを確認しました。

3 つ目は、「自動 WLM で優先順位付けすると？」という題目で、デモンストレーションを実施しました。Amazon Redshift では、自動で最適なワークロード管理が行われます。バッチ処理やユーザークエリなどのワークロード毎にキューを分け、ビジネス上の要件によって優先度を割り当て、特定のクエリに対してリソースをより多く割り当てることができます。今回は、Amazon QuickSight で、データ分析用のグラフを準備し、Amazon QuickSight から Amazon Redshift に直接クエリを実行するように設定したものをデモンストレーションで使用しました。Amazon QuickSight の画面の実行速度は、他の処理が動いていなければ、約 12 秒で完了する処理です。Amazon QuickSigh t用のユーザーとは別のユーザーで、3 つのセッションから負荷の高いクエリを継続的に実行させた状態で、Amazon QuickSight の同一の画面を開いても、優先度の設定を変更していない状態では、結果が返ってくるのに約 43 秒かかることをお見せしました。続いて、Amazon QuickSight からの実行ユーザー用のキューに対して、優先度を「最高」に変更し、再度、Amazon QuickSight の画面を開くと、裏で重い処理は動いたままの状態であるにも関わらず、約 20 秒で結果が返ってくることをお見せしました。CPU の使用率が 100％近い状態になるケースにおいても、優先度設定が有効であるということを示したデモンストレーションとなりました。

4 つ目は、「Redshift Spectrum は速くなったのか？」という題目で、デモンストレーションを実施しました。Amazon Redshift Spectrum のパフォーマンスは継続的に向上しており、Amazon Redshift のローカルテーブルと Amazon Redshift Spectrum 上の外部テーブルの結合処理を高速化する機能として、Bloom filters を採用しています。今回は、TCP-H のクエリを用いて、結合処理の高速化についてデモンストレーションを実施しました。まず、今回のデモンストレーションで使用するクエリの概要について、Amazon Redshift Spectrum 上にある 60 億行の lineitem テーブルと、Amazon Redshift 上にある 2 億行の part テーブルを結合し、集計するクエリであることを説明しました。part テーブルについては、Where 句で絞り込みされるため、20 万行がフィルターされますが、通常であれば、Amazon S3 上の lineitem テーブルのデータはフィルターされません。ただし、Bloom filters が有効となった場合、Amazon Redshift Spectrum 上のデータもフィルターされるため、絞り込まれていることをシステムテーブル「SVL_QUERY_SUMMARY」の「rows_pre_filter」列の情報から確認を行いました。また、2019 年 6 月時点で同等の環境で確認した実行時間の半分程度の時間で実行できていることを補足しました。

最後に、ここまで話してきた内容を総括し、本セッションを締めくくりました。

ぼくのかんがえたさいきょうのデータ活用基盤〜データレイクって言うな〜 [slides]

青木峰郎様
クックパッド株式会社技術部

クックパッド社青木様からは、まずはじめに、データの価値を最も高めるための 2 つの考え方について共有いただきました。「誰でも分析できること」と「全てを分析できること」です。1 つ目は、社員全員が活用できる方がデータの価値が最大化できるということ、2 つ目は、多くのデータを活用できた方が価値のある分析ができると考えられているためです。これら 2 つの考えをもとに、構築されているクックパッド社におけるデータ分析基盤構築のポリシーは 3 点となります。1 点目は、SQL 中心であること。これは、SQL で 8 割の処理が行え、残り 2 割位は適当な言語で処理できることを想定しています。ここで、分析者は SQL を描く前提とされているそうです。2 点目は、制約のないデータ処理であること。データのサイズや出所、種類によってできることを制限されたくないためとのことです。3 点目は、フルオープン＆性善説であること。できる限り多くの情報、可能なかぎり強い権限をすべてのユーザーに出すということです。これら 3 点についてはあくまで目標であり、まだ達成できていないものもあるが、3 点を目指してデータ基盤を構築されているというお話から始まりました。

続いて、実際に構築されている分析系のデータフローについて、解説いただきました。データ基盤の中心に、Amazon Redshift が、ds2.8xlarge のインスタンスタイプで 8 ノードで構成されています。データ入力として、3 系統あり、データ出力として、3 系統で構成されています。1 つ目のデータ入力としては、他のアプリケーションのデータベースからのデータ連携であり、多くが MySQL であり、約 500 テーブルのデータが連携されます。2 つ目としては、ログであり、すべてのログは Fluentd 経由で、JSON の形式で連携され、Amazon Redshift に約 400 本程度取り込まれます。3 つ目のデータ入力としては、SaaS のサービスから取り出したデータの取り込みというお話でした。これら 3 系統から取り込んだデータを Amazon Redshift 上で約 1000 本の SQL を用いてバッチ処理を行いサマリーデータを作成します。また、データ出力としても 3 系統あり、1 つ目のデータ出力としては、管理画面での利用、2 つ目としては、BI ツールでの利用で、Tableau や Redash を利用されているそうです。3 つ目のデータ出力としては、他のアプリケーションへの連携としてバルクエクスポートが実行されているというお話でした。

また、Amazon Redshift 上で実装されるほとんどの処理については、SQL で実装されているというお話で、3 つの例についてご紹介いただきました。1 つ目の例としては、レシピ検索インデックス構築についての内容で、もともと Ruby コードで記載されていたものに対して、元データの集計・取得部分を中心に SQL に変換することにより、Amazon Redshift に変換した部分は数十倍に高速化できたそうです。一方で、レシピの分かち書きなどの複雑な部分は今も Ruby で実装されているというお話でした。また、2 つ目の例として、ユーザーに近い配送ポイントの検出のために、Amazon Redshift の空間関数を使うことにより、郵便番号からもっとも近いポイントを検出されているそうです。最後に、3 つ目の例として、検索語の頻度分析の部分で、単語の分割と正規化の部分のみ Amazon Redshift のユーザー定義関数で実装され、残りはすべて SQL で実装されているとお話いただきました。

次に、前述の 3 つのポリシーに基づいてデータ分析基盤を構築されていく中で、発生した 4 つの課題についてお話いただきました。1 つ目は、巨大テーブル、2 つ目は、負荷のスパイク、3 つ目は、アプリ DB 連携、4 つ目は、性善説 DWH にまつわる課題となります。

1 つ目の課題は、巨大テーブルにまつわる課題でした。クックパッド社において、全体のデータ容量は 90TB 〜 100TB でしたが、もっとも巨大なテーブルが 40TB 程度あり、次に巨大なテーブルが 15TB 程度で、残り数 TB で 400 テーブル程度あるといった構成となっています。もっとも巨大なテーブルは、5 分間隔で走るバッチ処理があるため、5 分間隔で更新しなければいけないという制約があるそうです。Amazon Redshift の内部テーブルにログデータを保持した場合、6 つの問題が発生したというお話でした。大量データが存在するためディスクが足りない、高頻度で書き込みを行うとコミットに時間がかかり書き込みが間に合わない、ソートキーを効かせるために VACUUM SORT ONLY コマンドを約 400 本のログに対して実行しないといけない、アプリケーション側で足した項目があると過去分を遡ってデータを入れ直す必要がある、アプリケーション側で項目を追加したがテーブル側の文字列の長さが足りない時に対処する必要があることや、テーブル側のカラムを事前定義しないといけないといったようなことが挙げられました。

解決策として、Amazon Redshift Spectrum が採用されました。クックパッド社の場合、Amazon S3 に JSON 形式でデータが1分間隔で格納されます。JSON 形式で格納されたデータを Apache Parquet 形式に変換する内製のツールを開発されることで解決されたというお話でした。また、1 つ 1 つ作成された細かい Apache Parquet 形式のファイルを約 6 時間ごとにファイルの結合処理を行い巨大な Apache Parquet 形式のファイルを作成することにより、Amazon Redshift Spectrum のパフォーマンスが 4 〜 5 倍程度向上されたそうです。AWS Glue でカタログを切り替えることにより、直近のデータと一定時間が経過したデータをユーザーは何も意識することなく透過的に参照できるため、一定時間経過したデータを参照すると知らないうちに高速になっているというお話でした。この解決策により、先に述べられていた 6 つの問題のうち 5 つについては、すでに解決されたというお話でした。残り 1 点となる、「カラムを事前定義しないといけない問題」については、実際に届いたログファイルからデータ型を推測して勝手にカラムを追加するという手法で解決予定というお話でした。Amazon Redshift Spectrum の実行速度としては、巨大テーブルの場合、Amazon Redshift Spectrum は Amazon Redshift の内部テーブルと同様、もしくは速い場合もあるというお話で、また、遅い場合も +10% 程度であるので許容できるというお話でした。RA3 インスタンスについては、クックパッド社においては、今のところあまりメリットがないというお話でした。理由としては、巨大なテーブルを Amazon Redshift Spectrum にすでに移してしまったため Amazon Redshift の内部テーブルのサイズが小さくなっているというお話でした。現時点では、RA3 インスタンスへの移行予定はないものの、RA3 インスタンスでしか使えない新機能などが出てくれば検討される予定というお話でした。また、Amazon Redshift Spectrum の外部スキーマは公開しないという Tips についても共有いただきました。

2 つ目の課題は、負荷のスパイクに関する課題です。クックパッド社では、12 時から 13 時過ぎまで、Tableau からのクエリが、Amazon Redshift のリソースを使い切ってしまうという状況でした。Tableau からのバッチクエリで、巨大なログを何年分も処理したり、イベントの前後関係を作り変えるような処理でログ同士を不等号条件で範囲ジョインしたり、巨大なログに対してユーザー定義関数を使うことなどがあり、これらの条件が重なると、Amazon Redshift のリソースが大量消費されてしまうということが起こっていたそうです。Amazon Redshift がリソースが大量消費されている間、他のクエリが止まってしまうというのが大きな課題で、巨大なクエリも動かしつつ、短いクエリだけはすぐに実行させたいということがあったそうです。

2 つ目の課題に対する 1 つ目の解決策として、Concurrency Scaling と Usage Limit を活用されたお話をされました。クラスターの負荷が高くなったタイミングで、Concurrency Scaling を活用することで、重いクエリは元のクラスター上で実行されますが、追加のクエリについては、上乗せされたクラスター上で実行されるため、平均 15％程度クエリの待ち時間を短くできることができたそうです。しかしながら、Concurrency Scaling は追加コストが発生するという点はありますが、1 日 1 時間分の無料枠があるため、Usage Limit 機能を活用いただき、1 時間のみ使用するように設定いただくことで有効利用いただいているそうです。また、2 つ目の解決策の案として、自動 WLM 機能も検証いただいているというお話でした。

3 つ目の課題は、アプリ DB 連携に関する課題です。他のアプリケーションのデータベースから取り込んでいるマスターテーブルは、約 500 個あります。アプリ DB から Amazon Redshift へのインポートの問題として、日次より高頻度で取り込みたいということ、テーブルごとにロード設定が必要であること、バッチでロード完了を待つのを忘れがちということがあったそうです。Amazon Redshift からアプリ DB へのエクスポートの問題として、SELECTする場合、メモリが溢れてしまうことがあるため使えないがカーソルはリーダーノードの負荷が高くなるということ、データを読む途中で DB コネクションが切れると再開が難しいということ、UNLOAD は Amazon Redshift 固有の SQL のため全プログラマが書くのは難しいということがあったそうです。

3 つ目の課題に対する1つ目の解決策として、インポートについては、1000 万行程度までの小さいテーブルについては、フェデレーテッドクエリ経由に切り替えることでいますぐ全てを解決できると考えられているというお話でした。大きいテーブルについては、フェデレーテッドクエリを使ってAmazon Redshift へのインポートの仕組みが良いだろうと考え現在検証中というお話でした。2つ目の解決策としては、エクスポートについては、HTTP API のアンロードサーバーを内製で作ることで解決されたというお話でした。HTTP API でクエリを受け付けて UNLOAD し、その Amazon S3 の URL を返すサービスというご説明でした。

4 つ目の課題は、性善説 DWH に関する課題です。全員に Amazon Redshift のスーパーユーザーを解放することはできないため、最低限行動を監査できる必要があるというお話でした。ただし、権限要求を申請式にすると、それを処理するデータ基盤チームがボトルネックになります。Amazon Redshift のデフォルトの場合、作成された直後のテーブルはオーナー以外は読めないため、全員がテーブルを作るたびに GRANT する必要があるという課題があったそうです。

4 つ目の課題に対する 1 つ目の解決策として、内製のツールを作ることで解決されたということでした。個人用ユーザーの作成、パスワードリセット、個人用スキーマの作成、スキーマ権限の取得などをコンソールから行えるそうです。2 つ目の解決策として、ALTER DEFAULT PRIVILEGE という Amazon Redshift の機能で解決されたというお話でした。この機能により Amazon Redshift のユーザーごと・スキーマごとにデフォルトの権限を設定できるため、デフォルトで、public（全ユーザー）の SELECT 権限がつくようにしておくことでフルオープンにできているというお話でした。

最後に、まとめとして、ここまでにお話いただいた 4 つの課題について総括いただき、本セッションを締めくくられました。

NTTドコモのデータ分析・活用基盤における Redshift 活用事例 [slides]

三瓶明仁様
株式会社NTTドコモサービスイノベーション部

早川裕和様
ドコモ・テクノロジ株式会社スマートソリューション開発部

NTTドコモ社は、通信事業とスマートライフ事業の大きく 2 つの事業領域があり、5G を含む通信サービスの提供であったり、コンシューマー向けや法人向けのサービス開発を実施されています。多種多様なデータが出力されているため、そのデータを活用することが、重要となっているそうです。NTTドコモ社の三瓶様とドコモ・テクノロジ社の早川様は、データ活用を行うためのビッグデータ統合分析基盤の開発・運用業務を主に行われており、今回は、そのビッグデータ統合分析基盤についてのお話から始まり、運用されている中で発生した運用課題やその解決策、また、Amazon Redshift の最新サービス・機能に関する活用事例と検証結果などについてお話しいただきました。

まずはじめに、NTTドコモ社では、膨大なデータを効率的・横断的に分析・活用できる基盤として、ビッグデータ統合分析基盤があり、そのシステム概要についてご説明いただきました。NTTドコモ社内のセキュリティ要件遵守のため、閉域網で構成する必要があり、VPC エンドポイント等 AWS サービスを活用して閉域網で構成されています。閉域網のため、開発・運用が手間であり、大変というお話でした。続いて、DWH 構成の変遷としては、2014 年 8 月より Amazon Redshift を ds2.8xlarge の125ノード構成で導入開始され、当時はもともと保持されていた Greenplum の環境もオンプレミス上で継続運用されていました。2017 年 1 月からは、ds2.8xlarge の 125 ノード構成のクラスターを追加されました。2020 年 1 月には、継続運用されていたオンプレミス上の Greenplum の環境もなくなり、Amazon Redshift のみで構成されるようになったそうです。現在は、2 台あった Amazon Redshift クラスターを 1 台に集約され、ds2.8xlarge の 125 ノード構成の Amazon Redshift クラスターが 1 台と Amazon Redshift Spectrum で約 3PB のデータを保持されているそうです。今回は、クラスター集約前にどのような課題があり、どのように解決して行ったのかについてご紹介いただきました。

クラスター集約前の課題として、運用課題という観点で、容量不足、コスト、パフォーマンス・負荷、複数クラスター管理という 4 つの課題と、ユーザーへの影響という課題があったそうです。特に、容量不足については、最重要な運用課題であったというお話でした。原因としては、1 日あたり 50TB 程度のペースでデータが日々増えて続けていること、アドホッククエリを実行する分析ユーザーによる予測困難な大量ディスクの消費が発生すること、また、複数クラスターで運用することによる重複データ保持といったことがあったそうです。容量不足問題への抜本的な解決策として、Amazon Redshift Spectrum の導入と RA3 インスタンスへの移行という 2 つの案が検討されましたが、後述する RA3 インスタンスの検証結果と現行クラスターのリザーブドインスタンス期限に関わる移行スケジュールなどの都合を鑑み、今回は Amazon Redshift Spectrum を採用されたというお話でした。

続いて、Amazon Redshift Spectrum 導入要件と移行時の課題について、5 つの観点でお話しいただきました。セキュリティ、移行計画、パフォーマンス維持、コスト、ユーザー利便性についてです。

セキュリティについては、200 項目以上の社内セキュリティ要件を満たす必要があり、設計に苦労されたそうですが、Amazon Redshift の機能追加などもあり、全て満たした状態で運用開始することができているそうです。その中で、3 点についてご説明いただきました。1 つ目の要件として、パブリック経路を経由せずプライベート経路でのみ完結する必要があることがあげられました。Amazon Redshift Spectrum を利用するにあたり、外部テーブルのメタデータ管理に AWS Glue データカタログを採用いただいており、そのため、Amazon Redshift から AWS Glue、Amazon Redshift Spectrum 利用時の Amazon S3 へのアクセスをプライベート経路で接続する必要があったそうです。これらの要件は、AWS Glue の VPC インターフェースエンドポイントと Amazon Redshift の拡張された VPC ルーティングの有効化を行うことで、プライベート経路でのみのアクセスを可能とすることができたというお話でした。2 つ目の要件として、データは全て暗号化する必要があることがあげられました。暗号化の対象として、AWS Glue データカタログと、Amazon S3 上の外部テーブルの実データの暗号化があったそうです。Amazon Redshift Spectrum 利用時の Amazon S3 については SSE-KMS を当初利用されていたそうですが、外部テーブルに対して、Amazon Redshift クラスターの構成するノード数が多いことから、クエリを実行した際に AWS Key Management Service（KMS）の API コール上限を超過するという事象が発生し、API コール数の試算が困難であったこと、また、SSE-S3 でもセキュリティ要件を満たすことができることから、SSE-S3 へ切り替えられたというお話でした。3つ目の要件として、ユーザー・運用者でそれぞれ権限を分離できる必要があることがあげられました。Amazon Redshift Spectrum 利用にあたりユーザーも Amazon S3 へのアクセスが必要となったため、Amazon Redshift に付与するロールを用途ごとに分離し、運用者に必要な PUT 権限などは別ロールを作成し、信頼関係を用いることで、運用者のみ利用可能とすることで権限分離を実現されているというお話でした。またテーブルに対する権限の分離として、それまでは Amazon Redshift のスキーマ単位で権限を分離されていましたが、外部テーブル利用時は、AWS Glue にスキーマという単位がないため、AWS Glue のデータベースと Amazon Redshift のスキーマを紐づけることで、同等のアクセス権限分離を実現されているというお話でした。

移行計画については、それぞれ約 2PB のデータを保持していた 2 つのクラスターを 1 つのクラスターに集約するために、2つの課題があったそうです。両クラスターともデータ容量が 90％を超えているためそもそも移行のための空き容量がないこと、また、クラスターごとに保持データの種類が異なるため、合計 4PB 程度のデータを最終的に 1 つのクラスターの 2PB 以内に納める必要があったそうです。今回は、Amazon Redshift の内部テーブルの一部のデータを Amazon Redshift Spectrum の外部テーブル化することで、データ移行を実施されたというお話でした。データ移行を行う前に、月や日単位でテーブルを作成しているデータを対象にユーザーの利用傾向を調査し、3 ヶ月以上前や半年より前は利用頻度が低いといった傾向が判明したそうです。ユーザーの利用が少ないデータを対象に Amazon Redshift Spectrum の外部テーブル化を実施されました。実際の移行方法についても解説いただき、Amazon Redshift Spectrum を活用いただくことで、約 4PB だったデータを約 2PB に納めることができたというお話でした。

続いて、パフォーマンス維持のための取り組みについてお話いただきました。既存の Amazon Redshift と同等のクエリレスポンス性能を担保するために、2 つの対策を実施されたそうです。1 つ目の対策としては、クラスター集約に伴う負荷集中の解消というお話でした。もともと、2 つのクラスターでそれぞれデフォルトキューのみで、15 並列と設定されていて、常時 9 割以上使用されていたものに対し、移行後は 1 つのクラスターでデフォルトキューのみで、15 並列と設定され、その結果、待ち時間が大幅に増加したため、対応された内容についてご説明いただきました。運用キューとユーザーキューに分けることで、WLM によるクエリ振り分けを実装されたそうです。また、運用 ETL に必要な最低限の並列実行数を確保されたいということから手動 WLM を採用いただいているというお話でした。ただし、夜間帯はユーザーのクエリ数が減るため確保した並列実行数が無駄になるということから、スクリプトから AWS API を実行させることで、日中時間帯は、ユーザーキューの並列実行数をより多くし、夜間の時間帯は運用キューの並列実行数を多くすると言った形で切り替えることで、リソースの有効活用をされているということもお話いただきました。現在は、両方のキューを合わせて 25 並列で実装いただいているというお話で、その結果、15 並列では処理できなかった運用 ETL が回るようになったというお話でした。2 つ目の対策としては、Apache Parquet ファイルの使用・ファイルサイズ調整による高速化というお話でした。データレイクエスクポートを利用いただき、Amazon Redshift から Apache Parquet 形式でファイル出力される運用を実装されているそうです。出力ファイルサイズについては、いくつか実際の環境で検証いただいた結果、該当の環境では 512MB が他のファイルサイズに比べ、1.1 〜 1.2 倍の実行速度であったというお話でした。

コストの維持管理についての取り組みについてもお話いただきました。Amazon Redshift Spectrum の利用コストを効率的に管理するために、いくつかの対策を実施されているそうです。WLM のクエリモニタリングルールを活用いただき、Amazon Redshift Spectrum のスキャン行数やスキャンサイズなどの閾値をあらかじめ設定しておき、閾値を超えるようなクエリが実行された際は、自動的にログを取得したり、クエリ自体を停止したりするような機能を活用いただいているそうです。また、Amazon CloudWatch や BI ツール（Redash）を用いて日々 Amazon Redshift Spectrum の利用状況をモニタリングされているというお話で、実際の画面例も交えながらご説明いただきました。

5 つ目の課題として、ユーザー利便性を担保するための取り組みについてもお話いただきました。ユーザーの利便性を担保するために、外部テーブルと内部テーブルを意識せずにユーザーが利用できることを前提として考えられたそうです。一定期間経過したテーブルについては外部テーブル化を実施されていますが、その際にスキーマ名やテーブル名が従来の名前と異なるため、ユーザー関数とデータのアクセス先が変わることになるため、遅延バインドビューを使用して、内部スキーマ上にもともとあったテーブルと同じ名前のビューを作成し、ユーザーは作成したビューにクエリを投げることで、外部テーブルに透過的にアクセスできるように実装されているというお話でした。

また、Amazon Redshift Spectrum 導入以外の取り組みについても、ご紹介いただきました。容量改善に関連して、スキーマに使用可能なストレージスペースの上限が設定できるスキーマストレージクォータ機能をご利用いただいているというお話でした。スキーマストレージクォータ機能を導入するまでは、1 ユーザーが 20 〜 30TB といった大量のデータを利用されているケースもあったそうです。しかしながら、スキーマに使用可能なストレージスペースの上限を設定することにより、ユーザーのディスク消費を抑えることができ非常に有効であったというお話でした。RA3 インスタンスの導入検証については、検証概要と検証結果について共有いただきました。コストの観点から、ds2.8xlarge の 125 ノード構成と同程度になる ra3.16xlarge の 50 ノード構成で検証いただいた結果について共有いただきました。検証方法としては、ビッグデータ統合分析基盤で頻繁に利用されるクエリを模したベンチマークテストを実施いただき、4 つのパターンでそれぞれ実施いただいたそうです。現行クラスターについては、夜間の利用頻度の低い時間帯で実施されたというお話でした。今回実施された検証では、DS2 インスタンスとの比較において、必ずしも RA3 インスタンスが勝つという訳ではなかったこと、特に大量データをに対してフィルタリングを行ったあと、書き込み処理を行う特定の処理については、DS2 インスタンスの方が早いという結果となり、特定のユースケースでは RA3 インスタンスに優位性があるが、コストをかけて移行を行うほどの性能改善が見られなかったという結論に至ったそうです。現在プレビュー中である AQUA についてご期待いただいているというコメントをいただきました。また、空間関数の活用についてもご紹介いただきました。Amazon RDS では実現できなかったペタバイト規模でも高速に位置情報を分析することが可能になったというお話でした。ドコモ社の環境で 100 ノード構成の Greenplum と比較した場合、Amazon Redshift、ds2.8xlarge の 6 ノード構成で検証いただいたところ、ほとんどの関数で、数十％以上の時間が短縮できたそうです。これにより、位置情報分析の利活用が促進され、かつ、オンプレミス上の Greenplum 環境も廃止することができ、クラスター集約もできるようになったというお話でした。

最後に、Amazon Redshift Spectrum やスキーマストレージクォータなどの新機能の導入により、様々な運用課題を解決することができたとお話いただきました。また、Amazon Redshift Spectrum への移行と、空間関数のリリースにより、DWH クラスターも1つのクラスターのみに集約することができ、複数管理の煩雑さから解放されたというお話でした。また、RA3 インスタンスの AQUA によるさらなるパフォーマンス向上にご期待いただいており、GA（General Availability）された際は導入評価いただく予定というお話で締めくくられました。

まとめ

今回は、 Amazon Redshift の最新テクノロジーを現場でお使いいただいているお客様より、貴重な生の体験談をお話しいただきました。Amazon Redshift の利用に興味を持っていただいたお客様、また Amazon Redshift に限らず、AWS のサービスを利用することをご検討いただいているお客様がいらっしゃいましたら、無料で個別相談会を開催しておりますので、こちらのリンクからぜひお申し込みください。

Amazon Web Services ブログ