はじめに ～ざっくりAmazon RDS Custom～
Amazon RDS Custom(以下RDS Custom)は、Amazon RDS(以下RDS)のセットアップ、運用保守、スケーリングの自動化といった機能はそのままに、ユーザがカスタマイズできる範囲がRDSより広くなったマネージドデータベースです。
RDS Customでは、基盤となっているOSに特権ユーザとしてアクセスする、当てるパッチの種類・タイミングをユーザがコントロールする、といったことができます。
ユースケースとしては、パッケージソフトの要件的に個別パッチを当てたい場合や、RDSでは利用できない機能・構成を利用したい場合(RDS Custom for SQL Serverであればデータベース数の制限緩和など)が挙げられます。
(参考)以下に「RDS Custom for SQL Server では、DB インスタンスごとに最大 5,000 のデータベースを扱えます。」という記述があります。
RDS CustomはRDSと比較してユーザが制御できる範囲が広くなりますが、RDS Customにはsupport perimeterというモニタリング機能があり、ユーザのカスタマイズが要件を満たしているかを定期的(30分ごと)+スナップショット取得などのイベント契機で確認しています。
確認項目にはRDS Custom Agentが実行されているか、Systems Manager Agentが実行されているか、DBインスタンスのタイプが作成時の設定と同じであるか、などがあり、要件を満たしていないインスタンスはsupport perimterの外に出る=サポートされていない設定(unsupported-configuration) 状態になります。
unsupported-configuration状態のインスタンスは、スナップショットや自動バックアップが作成できないなど、利用できる機能に制約がかかります。
今回はunsupported-configurationになったときの挙動を確認したく、個人の検証環境でRDS Customを作成してunsupported-configuration状態を作りました。
以下の操作はDBインスタンスをサポートされない状態に置くものになります。
ご自分で試される場合は作業するアカウント、環境など十分に注意し検証してください。
1. RDS Custom for SQL Serverを作成する
今回はRDS Custom for SQL Serverを作成しました。
RDS Customを作成するとdo-not-delete-rds-custom-database-*という名前のEC2が作成されます。
構成図は以下のようになります。
RDSとは異なり、RDS CustomのDBインスタンスはVPC内にあります。アプリケーションからDBインスタンスにアクセスする場合はEndpointに接続しますが、今回はホストOSにSystems Managerでアクセスします。
2. RDS Customをunsupported-configuration状態にする
トラブルシューティングのドキュメントからunsupported-configurationになる条件をピックアップしてみます。ドキュメントによるとRDS Custom Agentは常に実行されている必要があるので、Agentを止めてしまえばsupport-perimeterから外れるようです。
RDS Custom AgentはSystems Manager Agentが実行されていることを確認する、といったDBインスタンスのモニタリングを行い、support perimeterに通知を送信します。(下記参照)
RDS Custom Agentを止める
RDS CustomのホストOSに接続してRDS Custom Agentを止められないか試してみました。
プロセスを見てみるとRDSCustomAgentがいますね
最初にStop-Processコマンドでプロセスを止めてみましたが、すぐに再開されました。
Amazon RDS CustomのDBに関する問題のトラブルシューティングによると「RDS Custom for SQL Server では、停止したエージェントはモニタリングサービスによって回復します。」とあったので、プロセスを止めても即回復するようです。
じゃあRDS Custom Agentを消せないか…ということでホストOSのディレクトリを見て回ったところ、C:¥Program Files\RDSCustomAgent\currentにRDSCustomAgent.exeがあったのでRemove-Itemしてみました。
削除したRDSCustomAgentの戻しは試していません。削除後戻す方法があるのかは不明です。
RDS CUstom ホストOS内のC:\Program Files\RDSCustomAgent\current内のアイテム(一部)
C:¥Program Files\RDSCustomAgent\currentでRemove-Item .\RDSCustomAgent.exeした後
RDSCustomAgent.exeが削除されている
今回RDS Customの作成時に2つEC2インスタンスが作成され、どちらにもRDSCustomAgent.exeがありました。
片方のインスタンスではRDSCustomAgent.exeは削除できたものの、もう片方のインスタンスではアクセス権限が無い、ということで削除できませんでした。(上の画像はRDSCustomAgent.exeを消せたインスタンスのもの)
片方のインスタンス(Agentを消せなかったほう)がメイン、もう片方(Agentを消せたほう)のインスタンスがサブ、のような立ち位置になっているのかな？とも考えましたが、確証は得られずでした。
RDS Customの状態を見てみるとunsupported-configurationになっていたので、片方のインスタンスだけだけどRDS Custom Agentアンインストールしたからね、と思ってシステムノートを見たら別の原因でした。それが以下になります。
EC2インスタンスプロファイルに必要な権限がアタッチされていない
sqs permissionが原因と言われている
以下を見ると、マルチAZ配置の前提条件にDBインスタンスがSQSと通信できる、というものがありました。
必要な権限(s3:putObjectなど)がRDS Custom作成時に指定したEC2インスタンスプロファイルに付与されていない場合、基本的には作成時にエラーが出て作成に失敗します。
ただ今回はSQS関連のロールが全くアタッチされていない状態でも作成ができました。
作成はできたものの、EC2インスタンスがSQSと通信しようとしたときに権限が無く、unsupported configuration was used for sqs permissionと言われてしまったように見えます。
(参考)EC2インスタンスプロファイルに追加する必要のあるロール
3. unsupported-configuration状態のときのRDS Custom
データベースの状態がunsupported-configuration(サポートされていない設定)のとき、スナップショットの取得がグレーアウトになっており、選択できませんでした。
EC2インスタンスプロファイルの設定を変更してEC2インスタンスがSQSと通信できるようにしたところ、ステータスが「利用可能」になりスナップショットの取得も選択できるようになりました。
この時片方のインスタンスのRDS Custom Agent.exeは消えたままですが、ステータスには影響していないようです。
おわりに
今回はデータベースが作成できたところで権限の設定はクリアしたかなとほっとしていましたが、まさかSQSの権限でunsupported-configurationになるとは思いませんでした。結果的にunsupported-configurationのときどんな感じになるのか、というのが実際に見れて勉強になりました。
今回色々検証してみて、RDS Customはユーザがいじれる範囲が広がりますが、カスタマイズのためにホストOSにアクセスするときなどは操作気を付けないとな……と改めて感じました。(2つのうち1インスタンスだけですが、RDSCustomAgent消せてしまったので…)
今回は個人の検証環境でデータベースを新規作成して検証を行い、検証後はデータベースを削除しました。本記事の操作(特にRDSCustomAgentを消すところ)はデータベースの稼働にはよろしくないので、繰り返しになりますが、検証する際は作業するアカウント、環境など十分に注意の上検証してください。
記事の内容的にWarningが多くなってしまいました……
今後の課題として、RDSCustomAgentなどRDS Customの稼働に必要なエージェントを削除してしまったとき、復活させることは可能なのか調べたいです。
参考サイト
RDS Customについて
support perimeterの定義や挙動について