こんにちは！
アスクルでインフラエンジニアをしている谷村です！
主に、AWSを使ったインフラの構築・運用をしています。
今回は、「カスタムエンドポイント」の検証・実装したので、備忘録としてゆる〜く記事に残します！
特に導入するにあたって、疑問がいくつかあったのでそこを検証したのでまとめておきます！
ドキュメントがすごく少ない印象なので、これから利用しようと考えている方の参考になればと思います！
「カスタムエンドポイント」って？
まず、「そもそもカスタムエンドポイントってなに？」っていう話からですが…。
簡単にいうと、
「特定のDBリーダーインスタンスにのみアクセスできるようにする機能」
です！
Amazon Auroraの機能の1つで、一部のリーダーインスタンスにのみアクセスできるように、専用のエンドポイントを作成し、リクエストを処理するインスタンスを分けることができます。
これにより、DBに対する負荷を分散させることや、特定のリーダーインスタンスにのみアクセスを集中させることが可能となります。
いわば、グループ分けのようなもので、インスタンスをそのグループに入れることをアタッチといいます。カスタムエンドポイント側にインスタンスをアタッチすると、そのエンドポイントに向けてリクエストが送られた場合、そのインスタンスメンバーにのみリクエストが処理されるようになります。
例えると、複数人メンバーが所属しているチームがあったとして、リーダーエンドポイントは、「〇〇チームの誰でもいいからこれやっといて！」なのに対し、カスタムエンドポイントは、「〇〇チームのXX担当のA君とB君、これやっといて！」っていう感じです！（伝われ）
カスタムエンドポイントのメリットデメリット
メリット
- 専用のエンドポイントを利用し、リクエストによって処理するインスタンスを分けることができ、負荷分散が可能
- スロークエリなどの重いリクエストを他と分けて処理でき、他のリクエストの処理性能への影響を抑えられる
デメリット
- カスタムエンドポイントごとにスケーリングできない（オプションでスケーリングによって作成されたインスタンスのアタッチが可能だが、負荷が高いカスタムエンドポイントに狙ってアタッチするのは難しい）
- クラスタリーダーエンドポイントに接続した場合、カスタムエンドポイントは関係なく、全インスタンスへ処理が振られる（カスタムエンドポイントを複数運用することで対策可能ではある）
導入のきっかけ
実は、以前から一部のリーダーインスタンスに処理が集中し、DBの性能が劣化している問題がありました。
調査すると、リクエストの1つにスロークエリが存在していることが分かりました。
そのスロークエリを含む重いリクエストを処理する際に、リーダーインスタンスが高負荷状態となり、他のリクエストにも悪影響を及ぼしていました。
そこで、見つけたのが「カスタムエンドポイント」でした。
カスタムエンドポイントを使用することで、スロークエリの処理を特定のリーダーインスタンスにのみ行わせ、他のリクエストへの影響を抑えることができないかと考えました。
ただ、カスタムエンドポイント実装にあたり、ドキュメントの少なさなどからいくつかの懸念点が払拭できず、実際に検証する必要がありました…。
検証内容の一部を次にまとめます！
懸念点（1）：カスタムエンドポイントに対するスケーリングの挙動は？
今回の実装では、DBの全リーダインスタンス（以降「DB全体」）を2つのカスタムエンドポイントに分けました。各エンドポイントを通常処理A用と激重処理B用といったように、リーダー処理のリクエストを効果的に分散させる形を取りました。
そこで疑問が1つ。
カスタムエンドポイントに対してオートスケーリングが行われた場合、どのような挙動になるのか？
そもそもカスタムエンドポイントを導入している場合、スケーリングの閾値の対象はDB全体のCPU使用率なの？ また、スケーリングされたとして、追加されたインスタンスはカスタムエンドポイントにアタッチされるの？
次々と疑問が出てきて、どのような挙動をするのか、という懸念がなかなか払拭できませんでした。
なので検証してみました。
検証結果
まず、1つ目の疑問、カスタムエンドポイントを導入している場合、スケーリングの閾値の対象はDB全体のCPU使用率なのか？ というところですが、結論からいうと、
YES
です。
カスタムエンドポイントを導入していても、スケーリングの閾値はDB全体のCPU使用率が対象となります（実際、スケーリングにそういった類の設定項目がなかったので想像はついてました。）
次に、スケーリングされた場合、追加されたインスタンスはカスタムエンドポイントにアタッチされるのか、というところです。
こちらも結論からいうと、
どちらにもアタッチされない
でした。つまり、標準設定ではどちらのカスタムエンドポイントにもアタッチされることはありません。
通常のDBクラスタにリーダーインスタンスとして作成されます。
しかし、カスタムエンドポイントには、次のようなオプションがあります。
「今後追加されるインスタンスをこのクラスタにアタッチする」
そうです。読んで字の如く、追加されたインスタンスを自動でアタッチしてくれます。
そのため、このオプションを有効にしたカスタムエンドポイントには、スケーリングによって作成されたインスタンスが自動でアタッチされます。
ちなみに、両方のカスタムエンドポイントで「今後追加されるインスタンスをこのクラスタにアタッチする」を有効にした場合どうなるのでしょう。
みなさんの予想どおり、どちらにもアタッチされます。
（処理を分けたいのに、追加された1台がどっちにもアタッチされちゃったら困るのでここは気をつけましょう👍）
懸念点（2）：カスタムエンドポイントのメンバーを編集中は、リクエスト処理可能なの？
AWSコンソール上で、カスタムエンドポイントを選択すると、この画面にいけます。 この画面からアタッチするインスタンス（以降「メンバー」）をいじれるのですが、色々いじっていた時、あることに気がつきました。
メンバーを編集したら、カスタムエンドポイントが「変更中」になってる!?
この状態で、カスタムエンドポイントにリクエストを投げたら、一体どうなっちゃうんだ〜!?
ということで検証しました。
検証結果
結論、処理できます。
カスタムエンドポイントのメンバーを追加したり、削除したりしても、リクエストは引き続き処理されるようです。
実際に、編集中のカスタムエンドポイントにリクエストを投げてみましたが、問題なく処理されました。
AWSサポートに確認したところ、この辺はカスタムエンドポイント側でよしなにリクエストの振り分けをやってくれてるみたい。👀
（カスタムエンドポイントにインスタンスがアタッチされてから初めて、そのインスタンスに処理が流れるようになるそう。賢い。）
懸念点（3）：激重処理用リーダインスタンスたちがライターになったらダメじゃない…？
カスタムエンドポイントを用いて、通常処理と激重処理を分けることはできそうだとわかりました。
が！
1つ懸念点があることに気づきました…。
もし何かしらの理由で、フェイルオーバーが起きてしまって、激重処理用のリーダーインスタンスがライターインスタンスになってしまった場合…
激重処理と書き込み処理が同じインスタンスで行われることになり、今度はライター処理が性能劣化してしまいそう！
流石に激重処理側がライターに昇格してしまうのは目を背けられないので、Auroraだけでなく、利用できるものはすべて利用してこの懸念点を解決してやろうと思いました！
最後にこの実装を紹介します！
実装の流れ
まず、フェイルオーバー優先順位ってなんだ、を説明しておきます。
フェイルオーバーが発生した際に、どのインスタンスを優先的にライターに昇格させるかを、インスタンスごとに重み付けできます。
これもAuroraの機能の1つであり、優先順位が高いほどライターに昇格しやすくなります。
勘のいい方なら分かったと思いますが！
この機能を利用して、ライターに昇格しないようにできる、っていうわけです。🕵️
ということで、激重処理用のリーダーインスタンスのフェイルオーバー優先順位を低く設定してみました。
が、オートスケールによって作成されたインスタンスを見てみると…。
あれ、君のフェイルオーバー優先順位も「15」なのかい。
なかなか一筋縄ではいきませんね。😢
どうやら、オートスケールによって作成されたインスタンスは、デフォルトでフェイルオーバー優先順位が「15」に設定されるようでした。
このままではダメなので、少し構成を工夫する必要がありました。
そこで登場するのが、"EventBridge"と"Step Functions"です！
これらリソースを用いて、次のように組み合わせると、オートスケールによって作成されるインスタンスのフェイルオーバー優先順位を変えられそうということに気づきました。
EventBridgeを用いて、オートスケールによってインスタンスが作成されたタイミングでStep Functionsを実行。 → Step Functionsで、作成されたインスタンスのフェイルオーバー優先順位を「1」に設定。
実際に実装してみると、狙いどおり！
オートスケールによって作成されたインスタンスのフェイルオーバー優先順位が「1」に設定されました！
フェイルオーバーの話、解決 🎉
これで、カスタムエンドポイントの導入にあたっての大きな懸念点をすべて払拭できました。めでたし、めでたし。
といった感じで
他にもいくつか細かい懸念点もありましたが、すべて実際に検証して、問題ないことが確認できたので、無事導入できそうということに！
といった感じで、カスタムエンドポイントの検証・導入までの内容を簡単ですが、まとめてみました！
実際に自分の目で確かめることは大事だなと改めて思わされた検証でした…。
「誰かの検証のお手伝いになればいいな！」とか、「誰かの疑問が解消されたらいいな！」とかを願いながら、終わりにしようと思います。
お付き合いいただきありがとうございました〜！
