この連載の第3回、第4回で、Amazon Redshiftの起動をはじめデータのロード、そしてローカルマシンからのクエリ実行と、一通りの操作に触れてきました。今回は、よりAmazon Redshiftの内部に踏み込み、Redshiftクラスタのアーキテクチャからスケーリングとリストアの方法について説明を行います。

Amazon Redshiftのアーキテクチャ

まずは、Amazon Redshiftのアーキテクチャについて見ていきましょう。

図1のように、Redshiftクラスタの内部は、大きくはクライアントとのインタフェースの役割を担うLeader Node（リーダーノード⁠）⁠、およびリーダーノードから送られてくるタスクの処理を担当するCompute Node（コンピューティングノード）に分かれます。それでは、図1のそれぞれの項目について見ていきましょう。

Leader Node（リーダーノード）

リーダーノードは、クライアントのアプリケーションとのやりとりを行い、SQLの解析、コンピューティングノードへのタスクの割り振りなどを行います。また、Redshift上で保持するテーブルの情報や統計情報などもこのリーダーノードで保持し、コンピューティングノードに問い合わせをする必要が無いクエリはリーダーノードで処理され、クライアントへ結果を返します。1つのクラスタにつき1つのリーダーノードが存在し、このリーダーノードの利用に対する課金は行われません。なお、第3回のようにシングルノードで起動した場合は、リーダーノードとコンピューティングノードの機能を合わせもった1台の構成となります。

Compute Node（コンピューティングノード）

コンピューティングノードは、リーダーノードがSQLを解析して生成したタスクを受け取り、実際の処理を行います。このノードは、数を増やしたり、もしくはノードのタイプを変更することで容量、性能ともにスケールさせることが可能です。ノードタイプは容量2TBのXLノードタイプと、16TBの8XLノードタイプをサポートします。ノードは最大100台並べることができ、最大容量としては8XLノードタイプを100台並べた1.6PBになります。課金もこのコンピュータノードのタイプと台数に応じて行われます。料金やノードタイプの詳細はこちらに記載されています。

Node Slice（ノードスライス）

コンピューティングノードの内部は、1コアあたり1つのスライスとして複数のスライスに分割され、それぞれのスライスにメモリやディスクのスペースが割り当てられます。リーダーノードは、スライスに対してデータの配置を管理し、SQLの実行などもスライスに対して行います。なお、各スライスは独立しているため、並列に処理させることが可能です。

Amazon S3

コンピューティングノードは、Redshiftクラスタに保存されているデータのバックアップ（スナップショットの配置）先として、Amazon S3を用いています。Redshiftクラスタをシャットダウンする際にも、S3にスナップショットをとっておくことで、次回S3上のスナップショットからリストアして起動することができます。起動中のクラスタと同じ容量（最小構成の場合は2TB）まで無料で利用でき、デフォルトで1日に1回自動でスナップショットが保存されるようにスケジュールされています。なお、ユーザが直接S3のバケットにアクセスすることはできません。

このように、Redshiftはコンピューティングノードの増減により、容易に容量と性能をスケールさせることを可能としています。次はスケールの方法について説明します。

Redshiftクラスタのスケーリング（リサイズ）の方法

Redshiftクラスタをスケール（リサイズ）させる際のパラメータとして、ノードタイプとノード台数を変更することが可能です。リサイズの方法は非常に簡単で、クラスタ詳細画面から"Resize"ボタンをクリックし、リサイズ後のノードタイプとノード数を指定するだけでリサイズを行うことができます（図2⁠）⁠。リサイズをすればそのクラスタ構成に応じた料金が課されることになりますので、ご自身でリサイズをテストされる際には注意してください。

Node Tpye（ノードタイプ）

変更後の新しいノードタイプを指定します。

Cluster Type（クラスタタイプ）

Single Node（シングルノード）もしくはMdlti Node（マルチノード）が選択でき、マルチモードの場合にはクラスタのノード数を設定することができます。

Number Of Nodes（ノード数）

クラスタのノード数を指定します。

次に、実際にどのようなステップでスケールが行われるかについて説明します。

リサイズのステップ

Redshiftクラスタのリサイズは、次の手順で行われます（図3⁠）⁠。

1. 現行のRedshiftクラスタを読み取り専用モード（リードオンリーモード）に変更
   →これ以降、SELECTクエリなど参照系クエリのみ実行可能
2. リサイズ後として設定したRedshiftクラスタが新規に起動
3. 現行のRedshiftクラスタから、新規に起動したRedshiftクラスタへ全データをコピー
4. DNSを更新し、新しいRedshiftクラスタへと接続先を変更（切り替えの数分間無通信状態）
   →この間、Redshiftへの接続は失われ、新たなRedshiftへの再接続が必要

このように、リサイズ時には新規で指定したパラメータのクラスタが構築され、全データをコピーした後はそちらに参照を変更して利用することになります。最初のステップでは読み取り専用モードになるため、この間一切の更新ができなくなり、最後の切り替えの作業の間は参照もできなくなりますので、運用する際にはこのあたりの点について注意する必要があるでしょう。

このように、数クリックでデータベースをほぼダウンさせることなく簡単にスケールさせることができます。これは、まさにクラウドとして提供するAmaozon Redshiftならではの特徴と言えるでしょう。

スケーリングと性能の関係

スケーリングによる恩恵は、データの容量追加だけでなく、並列度が増すため大規模データに対するクエリの速度の向上にもつながります。図4のグラフは、私たちがRedshiftを検証した際、1.2TBのデータに対してそれぞれクラスタのサイズを変更して速度の計測をした結果です。

シングルノードに比べて、マルチモードで複数のコンピューティングノードを用いた方が、クエリの速度は明らかに速いことがわかります。もちろん処理するクエリの内容には依存しますが、用途によっては大規模なデータに対し、スケールさせることでよりAmazon Redshiftのメリットが生きる、まさに大規模なデータの用途に効果的なAmazon Redshiftの特徴がわかってもらえるかと思います。

Redshiftクラスタのバックアップ（スナップショット）とリストア

最後は、Redshiftクラスタのバックアップ（スナップショット）とリストアについて見ていきましょう。

アーキテクチャのところで説明した通り、RedshiftクラスタはS3バケットをバックアップストレージとして活用しています。自動で1日1クラスタのスナップショットをとるようになっており、また手動でのスナップショットの取得も可能です。手動でスナップショットを取得する方法は、対象とするクラスタの画面で"Take Snapshot"をクリックし、スナップショットの名称を入力した後"Create"をクリックすれば完了です（図5⁠）⁠。

続いて、作成したスナップショットからRedshiftクラスタをリストアをしてみましょう。メニューにあるSnapshotsをクリックして、スナップショット一覧の画面を開き、リストアしたいスナップショットを選択して、"Restore From Snapshot"をクリックします（図6⁠）⁠。リストアするRedshiftクラスタの入力画面が出てきますので、任意のものを入力し、"Restore"をクリックするとリストアが開始されます。

なお、リストアを行う場合、図6の画面にある通りの項目のみが変更可能となっており、それ以外の項目はリストア時には変更することができず、リストア完了後に修正する必要があります。

リストアの作業は以上です。このようにバックアップ、リストアともに非常に簡単に行うことができます。

スナップショットとリストアに関する注意

次に、スナップショットとリストアの注意点について紹介します。

自動スナップショットの削除条件

自動スナップショットは、該当のクラスタをシャットダウンした場合、もしくはスナップショットの保持期限が切れた場合に自動で削除されてしまいます。これを防ぐためには、上記で説明した方法のように手動でスナップショットを取っておくか、もしくは自動スナップショットをコピー（スナップショット一覧の画面で"Copy Automated Snapshot"をクリック）しておくかのどちらかを行う必要があります。なお、自動スナップショットは設定で停止させることも可能です。

スナップショットに含まれる情報

スナップショットには、ノード数、ノードタイプ、マスターユーザ名なども含まれます。リストア時にはこれらも含まれてリストアされますので、変更した場合には起動後にクラスタの画面から"Modify"で修正する必要があります。また、セキュリティグループは"Default"のみが設定されますので、こちらも必要に応じて修正する必要があります。

Redshiftストリーミングリストア機能

Redshiftのリストアのステップとして、最初にメタデータのみをロードし、実データはその後ロードされます。SQLの実行はメタデータのロードが完了した時から可能で、対象とするデータがクラスタ上に存在しない場合は、自動でS3から取得してくる仕組みとなっています。これをAmazon Redshiftストリーミングリストア機能と呼び、リストアの時間の大幅な短縮が図られています。実際にデータのロードに比べてリストアは格段に早く、筆者のケースでは1.2TBのスナップショットをロードする際も30分足らずで利用できるようになりました。ただし、完全にロードされるまではSQLの実行は遅く、筆者のケースではSQLの実行に通常の約2倍程度の時間を要しましたので、場合によってはこの点も考慮しておく必要があるでしょう。

今回は、Amazon Redshiftのアーキテクチャの説明から、スケーリング、バックアップ、リストアについて説明を行いました。いずれの操作も非常に簡単で、一時的で短期間だけRedshiftを利用したい、というニーズにも応えられるようになっており、ビッグデータを扱う幅広い企業にとって、Redshiftの導入が検討に値する理由のひとつになるものと思います。

筆者が所属する Hapyrusでは、Amazon Redshift を使いはじめるための継続データインテグレーションサービスFlyData for Amazon Redshiftを提供しています。また、Amazon Redshift の導入コンサルティングも無料で行なっていますので、興味がある方はぜひお気軽に info@hapyrus.com にお問い合わせください。