Redshiftで思うことつらつら。
はじめに
昨年、Redshiftを触り始め、思ったことなどをまとめます。
基本情報は、AWSの公式情報が一番です。
AWS Redshift ガイドライン
そして、サポートに問い合わせても、ガイドライン以上の情報は手に入りませんでした。。
なお、2019年末時点の情報です。
変化の速いサービスのため、今後の情報次第では解消されているかもしれません。
思ったことをつらつらと。
SQLのコンパイル問題。
いまだ何ともならないRedshiftの唯一の欠点。
BI製品などで裏でSQLが自動生成される場合に、SQL文が長い（1000行以上）と、数秒で終わるSQLがコンパイルで数分近くかかるため、性能問題になる。
⇒対応策：あらかじめSQLを流しておくしかない。
（過去に流れたSQLを抽出して、起動時に流す、自動打鍵ツールで流すようにするなど工夫が必要）
また、このコンパイルはあくまでキャッシュされた状況のため、
Redshiftのバージョンアップやスナップショットからの復元（疑似的に停止運用などをする場合）にも、削除されるため、その都度ケアが必要。
データウェアハウスとしてRedshiftは今後も選択肢に入り続けるかと思うが、
この部分が残り続ける以上、BI製品との相性はPOCなどは必要。
Redshift側でできるものは何もないため、BI製品側で頑張ってもらうしかない。
値段が高い！
スペックが高いに越したことはないが、Auroraなどと比べるとvCPU単位の値段がとにかく高い。
特にリーダーノードはスケールアップの選択肢が少なく、ボトルネックとなった場合のスケールアップの値段が大きいため、テストなどで確認が必要
Postgreのバージョンが古い！
postgre 8 で動いているため、物理DBの設定に癖がある。
作者はpostgre SQLのバージョン9.6 以降から触り始めたため、今までのユーザー定義や構文が使えないことに非常にストレスを感じた。
なお、SQLの構文等でも差異はある。ローカル環境でRedshiftを用意することは困難のため、早めにCI環境の構築が必要。
SQLチューニングの余地がほとんどない！（いいこと！）
分散キーとソートキーの設定のみのため、RDBであるいわゆるヒント句追加などのパフォーマンスチューニングがほとんどない。だいたい、分散キー、ソートキーの設定でうまくいかない場合、テーブル設計を要件等。
OracleやPostgre（RDB）などのDatabaseスペシャリストの出番があまりない。
ただし、テーブル設計は他のDatabaseと変わらず常に重要！
（補足）
- RDBに比べて、SQLの結合に弱いと聞くが、その影響をほとんど感じないほど、性能は良い。
分散キーの設定の影響か、特に問題なく利用できている。
- マスタテーブルの分散タイプについて、機能特性上ALL（各ノードそれぞれに配置）にすべきのようにみえるが、パフォーマンス観点上、EVEN(ラウンドロビン）でも影響なし。データ件数の問題か。（数千件クラスなら問題なし）、それ以外はKEYで指定する。
- 最近出てきたソートキーのinterleavedは、バキュームを個別対応に実施したり、同時実行スケーリングが効かないなどの問題があるため、特別必要でなければ避けたほうが良い。
データ挿入（移行作業など）
S3からファイルのインポートが可能だが、インポート後に別スレッド？（非同期）で、データの分散が始まるため、
瞬間的にディスクフル（OutOfMemory が出る）場合がある。
その場合、時間をおいてから実行すると、スケールアップせず、移行作業が続行可能。
ファイルのインポート、アップロードは、psql のPG_COPY コマンドは対応しておらず、公式に書かれている方法で実施するしかない。メトリクスを注視しながら、最適な並列実行を見極めると作業時間の短縮が可能。
耐障害性
よくあるAZ構成ができないため、耐障害性の要件定義がしづらい。実情として意外と落ちない。
むしろ、Auroraのほうが突然フェイルオーバーする回数が多い。（なぜ？）
サポート曰く、停止後の時間が早いとのこと。AZ障害などのNW起因を除けば、ノード単位の障害発生時は問題にならないかもしれない。とはいえ、非機能要件の定義の際に、他のAWSのサービスと同じように記載しないように気を付けること。
バージョンアップ
Redshiftはとにかくバージョンアップが速く、3か月に1回強制的なアップデートで、再起動が走る。
コンパイルの挙動など微妙に違うなど、リリースノートに記載できていないアップデートがある。過去、トラブルにはなったことはないが、詳細な挙動抑えていると「あれ」と思うことはある。
(個人的には特定のバージョンで確定していただけると安心。)
そもそもマネージドサービスのため割り切る必要があるが、運用として、バージョンアップ内容の確認、再起動のタイミング調整などが必要。
ディープラーニングの機能など、時代の技術を多く採用
動的ワークロード管理 (WLM)（各SQLが流れるときのキューの設計・管理が不要）、
Short Query Acceleration（過去実績のあるSQLで実行時間が短い処理は専用の別スレッドで流れる）の搭載、
同時実行スケーリング（起動直後に待機時間はあるものの、Select文は同時実行数の制御が増やせたり）と、ユーザーにとって使いやすくかつ時代の最新の技術が入っているので、率直にいって評価できるサービスである
AWSの開発現場の内部はわからないが、積極的に機能追加や技術採用などしていることを思うと、ワクワク現場なのかなと思ってしまう。