この記事の対象
CloudSearchを使い始めたばかりの方へ。
CloudSearchのことを良く知らないまま、運用を引き継いだエンジニアの方へ（私）。
内部動作について
スケールする時、何がおきているのか
CloudSearchはインデックス再構築の際に、S3上にその時点でのドキュメントとインデックスを保存します。
スケールが発生する際、このS3上のデータを読み込んでインスタンスが新規に起動するのですが、注意点として、インデックス再構築後にアップロードしたドキュメントは、インスタンスが立ち上がり、アクセス可能になった状態から随時更新されていきます。
この仕様は認識しておかないと、後述のように痛い目をみることがあります。
インスタンスタイプを変更する時、何が起きているのか
インデックス再構築が同時に走るため、非常に長い時間PROCESSINGステータスとなるインスタンスタイプ変更。
この間、本番環境に影響は無いのか？内部動作を知っていると、安心して実行できます。
結論として、ドキュメントのアップロードを実行し続けていなければ、本番環境には一切影響がありません。
- 変更前インスタンスにてインデックス再構築（EMRクラスターによる実行のため、変更前インスタンスには影響無し）
- 構築されたインデックスを用いて新規インスタンスが起動
- 2の直後、変更前インスタンスが削除される
もし1と2の間にドキュメントアップロードを行っていた場合、変更後のインスタンスが起動した後に、差分更新が発生します。
この更新が完了するまで、若干パフォーマンスが落ちる可能性があるようです。
変更の際は、あまり大量の更新を行わないのが吉ですね。
ハマったこと
NEEDS INDEXING状態だとオートスケールされない
2016/5の話ですが、オペレーションミスで、NEED INDEX状態のままサービス提供をしてしまい、スケールせずに応答不能となる事故が発生しました。
直前に気付いたため、再構築には非常に時間がかかるので、果たして本番サービス適用中にPROCESSINGにして何か問題が出ないか、非常にバタバタしました。上述の内部動作を知っていればそこまで慌てなかったんですが、、
これはよく考えると、逆手に取って負荷テストでスケールしたくないのにスケールしてしまう場合に利用できるかもしれないですね。
インデックス再構築をサボっていると、データが消えたと勘違いするかも
「スケールする時、何がおきているのか」の通り、完全にドキュメントが同期されてからアクセスできるようになるわけではないので、「あれっ、登録した筈のデータが無い！誰か消しちゃった！？」と慌てて再登録を行ったものの、全然改善されないなんでだー！という事故に遭遇しました。
もちろん本番サービスの場合、ドキュメント同期中のインスタンスにアクセスしてしまったユーザは「あれ？データが無い！」となります。
ちなみに管理コンソールのSearchbleDocumentsも、どのインスタンスにアクセスして返した数字か分からないので、当てになりません、、（インスタンス毎にSearchbleDocumentsを表示していて欲しかった）
差分ドキュメントが大量にあると、こうした事故に遭遇する可能性があります。
みんな、お金はかかるけど、こまめにインデックス再構築はしよう！（冷静に考えると、この仕様でインデックス更新に課金されるのって鬼仕様ですね、、）
boto3でDesired Replication Count管理してたらギャッとなった話
アクセスのバーストが予測される状況に備えて、CloudWatchルールからLambdaを呼び出して、事前増強するようにしてました。
で、当初はデフォルトのインスタンスで運用してたので、DesiredInstanceTypeはrequiredでもないし、指定してなかったんです。
ある時管理コンソールからインスタンスタイプを上げて、しばらくした後このツールを使ったら、恐怖のNEEDS INDEXIN状態（オートスケールしない）になってしまってました。
DesiredInstanceTypeを明示しないと、Use Defaultに変更する、と同義として捉えられてしまうようです。
幸い、PROCESSING状態であればちゃんとスケールするので手動対応にて事なきを得ましたが、ヒヤリハット事例でした。
まとめ
CloudSearchはちゃんと勉強しないと運用できないよ！安易に引き継いじゃ駄目だよ！
AWSサポートにはとてもお世話になりました。多謝。