はじめに
これは estieのカレンダー | Advent Calendar 2021 - Qiita 14日目の記事です。
estieのアドベントカレンダーには他にもいろいろな切り口の記事が書かれていますので、ぜひ一度タイトルだけでも覗いてみてください。
estie VPoEの青木です。
ハリネズミのerizo（スペイン語でハリネズミの意味から取りました）と暮らし始めて1年半。
日々のお世話にはだいぶ慣れてきたものの、アフリカにルーツがあるヨツユビハリネズミは25度以上の気温を維持する必要があるため、冬の季節は毎朝ヒーターの調子が悪くなってないかハラハラしながら過ごしています。
さて、冬の季節といえばAWS re:Inventの季節でもありますね。
大きなアップデートが多く発表されるre:InventはAWSを利用されている方ならば楽しみにしている方も多いのではないでしょうか。
今回は、特にRedshift / EMRのServerless発表が印象的でした。
Amazon Redshift Serverless の発表 (プレビュー)
Amazon EMR Serverless のご紹介 (プレビュー)
今回のRedshiftアップデートの印象
estieでは現状Redshiftは利用していませんが、前職アクセンチュア在職時の2019年までは大規模データ基盤構築のプロジェクトでRedshiftやEMRを多く利用していました。
私が利用していた2019年以前のRedshiftは、以下のような特性を有していました。
- 起動時にインスタンス数とインスタンスタイプを指定して起動
- インスタンスタイプはcomputing特化/storage特化の2種類だけ（それぞれ何種類かサイズあり）
- そのためcomputingリソースを一時的に増やしたいだけでも、storageも追加することが必要な場面が多い
- インスタンス数変更には長いダウンタイム（データ量によっては数日間）が発生する
一方で、Redshiftを用いてデータ分析基盤を構築するようなユースケースでは以下のような性質のプロジェクトも多いと思います。
- computingの利用量はバッチ処理の実行時間や、分析者の利用状況によりムラがある
- storageは徐々に増加するが原則として大きな変更はない
これらの特性がうまく噛み合わないと、処理実行数が少ない時間にstorage利用のために十分なインスタンスを立ち上げるとcomputingリソースが遊んでしまったり、逆に処理が多く実行されてcomputingリソースが必要な場面でスケールアウトをすることが難しく処理時間が長くなったりと、リソースをdynamicに最適化させるのが難しい場面が多くありました。
また、分析者の増加やデータ量追加に伴うクラスター構成変更を実施する場合長いダウンタイムが発生することもあり、基盤構築前のユースケースもまだ見えてない時期にデータ量や利用状況を精緻に読むという難度の高い要件定義が必要だった印象です。
Redshiftは2019年末のRA3インスタンスの登場以降、他クラウドサービスのことも意識しながらcomputingとstorageの分離の方向への改善が急速に進んでいると感じます。
Amazon Redshift で、コンピューティングとストレージの独立したスケーリングを可能にする、マネージドストレージが付属した RA3 ノードをリリース
今年のre:Inventで構成を意識せずにsmallに始めやすくなるserverless型が発表されたことは、この方針を加速させ、
我々のように分析の利用量が多くなく、運用負荷を担うのは避けたいと考えていたスタートアップにとっても利用しやすくなる発表だったと感じます。
そんな待望のserverless型のRedshiftについて、本記事ではサービスを利用する手順をご紹介したいと思います。
試してみた
はじめに
社内のAWSリソースはTerraformでリソース管理をしていますが、本記事ではすぐに検証するためにAWSコンソールを用いてRedshift Serverlessの利用を設定してみたいと思います。
serverlessエンドポイントの利用開始
AWSコンソールからRedshiftのサービス画面にアクセスすると、新たにServerlessのリンクが作成されてます。
ひとまずdefault設定でクレジットを利用するように設定。
trialのために500USDのクレジットが付与されています（ありがたい...）
最低限の設定を完了すると、起動中の画面になります。
少し待つと新しいエンドポイントが立ち上がりました。
（コーヒーを入れている間に準備できてました）
"Query data" と記載されたリンクをクリックすると、Amazon Redshift Query Editor V2が立ち上がりました。
これも私がRedshiftを利用していた際には提供されていなかったのでありがたい...
この画面を通して、databaseのテーブル情報を確認したりSQLを実行したりすることが出来ます。
また、分析者ごとにフォルダを分けてクエリを保存することや、可視化したチャートを保管するも可能です。
利用イメージをつけるために何かサンプルデータを読み込もうかと考えていたら、Editorからsampleデータを読み込むことが可能でした。
リンクをクリックするだけでTICKITサンプルデータベースを読み込んで、いくつかサンプルクエリがエディタ上に表示されます。
以下画像は、チケットの売上を分析するサンプルクエリです。
ここまでスムーズに準備完了し、簡単に利用イメージが湧きました。
ログデータを分析
もう少しestieでの利用イメージを湧かせてみようと思い、ログデータのサンプルをS3から取り込んでデータ分析をしてみようと思います。
まずはS3からデータを取り込めるよう追加でRoleを付与します。
ログデータを格納するテーブルについて、jsonの中身を確認して細かく必要なカラムを定義をせずにSUPER型としてrtextカラム（raw textの意図）を定義してみます。
半構造化データを Amazon Redshift にロードする - Amazon Redshift
こちらのSUPER型も私が利用していた時期には提供されていなかったのですが、2019年のre:Inventで発表されて最近GA（Generally Available）となった機能です。
この型を採用することで、ログデータのようなnestした構造を持ったうえで後からkeyが追加されうるようなデータについてもRedshiftに取り込んで探索的に分析することが可能になっています。
CREATE TABLE log_sample.public.logs (rtext super);
S3からのデータロードではconsoleでS3をbrowseしながらロード設定をすることも可能です。
今回はnoshredオプションを使ってSUPER型のカラムに全てまとめてロードしてみます。
COPY log_sample.public.logs2 (rtext) FROM 's3://path/to/your/file' GZIP IAM_ROLE 'arn:aws:iam::123456789012:role/RedshiftSpectrumRole' FORMAT AS JSON 'noshred' REGION AS 'ap-northeast-1' ;
rtextに挿入したデータを元に以下のように各keyの情報を取り出せます。
以前は頑張ってJSON_PARSEなど関数を組み合わせて必要なデータを抽出しないといけなかったのですが、SUPER型のおかげでrtext.messagesのようにデータを取り出せるのはありがたいですね。
SELECT *, is_object(rtext), rtext.messages, rtext.severity, rtext.time FROM public.logs ;
本格的にRedshiftを利用することになった場合、よく利用する項目の構造を取り出してマテリアライズド・ビューの形で用意するのも良いかもしれません。
こちらも2019年時点では提供されてなかった機能ですが、更新クエリを実行した際に追加されたレコード分から「増分リフレッシュ」を実施できます。
日々レコードが増えていくログデータのparseといった用途にも利用しやすそうです。
利用量の状況
ここまで殆どクラスターの設定や利用料金について意識せずに分析に注力出来ました。
ここで、一度利用量について確認してみましょう。
コンソール上で、管理画面でクエリ数やクレジット（Redshift processing units (RPUs)）の利用状況を簡単に確認できます。
しばらく時間が経過すると自動でRPUの利用が止まっていることが確認できます。
利用しない時間にsnapshotを作成してクラスターを停止して...といった管理業務を意識しなくてよいのは、本当にありがたいです。
完全に停止した後の状態からQuery Editorを起動してクエリを実行してみましたが、2-3秒ほど起動しクエリが実行できる状態になりました。
Redshiftでこのスピード感で分析環境を立ち上げてクエリ実行できるのは感動ものですね。
最後に
新しくre:Invent2021で発表されたRedshift Serverlessを利用してみました。
意識がデータや分析自体にフォーカスできて、我々のように少人数で開発しているスタートアップにとっては非常に使いやすいと感じました。
また、それ以上にこの2年間で、Super型やQuery Editor、マテビューの登場などかなりRedshift自体の使い勝手が上がっており、すこし浦島太郎状態のようになってしまいました笑
estieでは現状ログデータを元にユーザの利用状況を分析することも多いですが、このような基盤をRedshift Serverlessを用いて提供することも視野に他のオプションと比較して考えていきたいと思います。
estieではこのようなデータ分析基盤を改善していくエンジニアも募集しています！
ぜひ、一緒にどんな改善をしていくか考えてみたい方、一度ディスカッションベースでもお話させてください！
hrmos.co
hrmos.co
