まめ畑

ゆるゆると書いていきます

Redshiftの管理面

最近Redshiftの需要が高まっていますが、管理面のことをあまりみないので、簡単にまとめておきます。

ドキュメントは
Amazon Redshift

接続するには

postgresqlクライアントを使います
JDBCで接続する場合のdriverは: http://jdbc.postgresql.org/download/postgresql-8.4-703.jdbc4.jar を使います(バージョン指定です。8.4)

public access

RedshiftはVPC内やClassic環境からのアクセスの他にPublic Accessを許可できます。インターネット側からアクセス出来る経路を開けますが、SGでアクセス元を絞れます。また、こちらの設定は後で変更可能です。

クラスタの起動・削除時間

  • 双方ともに約5-10分(node数などによってそれ以上かかることもあります)
  • クラスタの削除では最大3時間程かかったこともあります。

maintenance

Redshiftにもmaintenance windowがあり、毎週こちらが指定した、曜日・時間でメンテナンスが行われます。Version UpgradeをONにしておくと、その時間に行われます。
動作詳細はまだメンテナンスを経験していないのでわかりませんが、数分Readonlyになり、新クラスタへ引き継がれるかダウンタイムになるかのどちらかなのですが、こちらは確認をしたいと思います。

Snapshot

自動Snapshotと手動Snapshotがあります。
Snapshotはクラスタを止めることなく、オンラインで取得されます。
EBSと同じで差分で取得している雰囲気がします。10−20%性能低下が見られましたが、許容範囲内かと思います。こちらは、データサイズやクエリによりますので、検証をしてみてください。

SnapshotからのRestoreは
f:id:con_mame:20130628210600p:plain
Restore From Snapshot

SnapshotからのRestoreで復元される情報ですが、上の情報を見ると分かる通りクラスタ情報も格納されます

  • ノード数
  • ノードタイプ
  • AZ
  • VPC
  • Subnet
  • User/pass
  • xDBC Endpoint

ここで便利なのは、接続先のEndpointのFQDNも復元されるため、Restoreして新しいクラスタを起動してもアプリケーションの接続情報を書き換える必要がありません。
しかし、SG情報だけが復元されないためクラスタ詳細画面のModifyから設定する必要があります。
f:id:con_mame:20130628210559p:plain

また、そのクラスタに対するEvent(クラスタ起動・停止・変更など)とノードのリソース使用状況はSnapshotに含まれますが、Queryログのパフォーマンスデータは含まれません。

アクセス権限

Redshiftは各ノードのCPUなどのリソース使用率やクエリごとの実行計画やリソース使用率がManagement Consoleから確認出来ます。
IAMに以下の権限をつけることで、Redshift readonly accessが可能になります。クエリチューニングなどの際にかなり役立つかと思います。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "redshift:Describe*",
        "redshift:get*",
        "ec2:DescribeAccountAttributes",
        "ec2:DescribeAvailabilityZones",
        "ec2:DescribeSecurityGroups",
        "ec2:DescribeSubnets",
        "ec2:DescribeVpcs",
        "ec2:DescribeInternetGateways",
        "sns:Get*",
        "sns:List*",
        "cloudwatch:Describe*",
        "cloudwatch:List*",
        "cloudwatch:Get*"
      ],
      "Effect": "Allow",
      "Resource": "*"
    }
  ]
}

リソース使用状況

Redshiftは以下の様にクエリ毎・ノード毎のリソース使用状況が確認出来ます(CPU/memory/swap/NW/Disk/latencyなどなど) また、Queryの実行計画も確認出来ます。

  • node毎

f:id:con_mame:20130628210603p:plain

  • Query毎

f:id:con_mame:20130628210558p:plain
f:id:con_mame:20130628210602p:plain
f:id:con_mame:20130628210604p:plain
f:id:con_mame:20130628210556p:plain

クラスタサイズ変更

Resizeから簡単に変更できます。
f:id:con_mame:20130628210555p:plain
注意点は1クラスタ内のノードスペックの違うものを混在できないといところだけで、オンラインでResize出来ます。

変更中はReadonlyになるためデータのインポートはできません。
仕組みは既存クラスタをReadonlyにした後、Resize後のクラスタを起動、並列にデータをコピーし、終わったらEndpointのIPアドレスDNS側で変更するという流れです。

監視

データのインポートはcopyコマンドを使うとS3やDynamoDBからノード数に応じて自動で並列化され高速に行われますが、エラーが起こった際は、SNSに対してメッセージ送ったりSQSにキューを入れることが出来ます。
そのため、形式エラーでない場合はSQSをみて再実行するスクリプトを書くことで自動リトライが可能です。

ClouwdWatchでもnode毎に監視可能です。
f:id:con_mame:20130628210601p:plain

全景

f:id:con_mame:20130628210557p:plain