さて、前回の記事から半年くらい間が空いてしまいましたが、皆様いかがお過ごしでしょうか。
この半年間、ちょうどコロナ騒動で生活リズムに変化があった方も多いのではないでしょうか。
私も毎日出勤していた生活だったのが、すっかり在宅ワークに変わってしまい、ほとんど電車に乗ることが無くなってしまいました。
さらに、飲みに行くことも全く無くなり、ランチであちこちのお店を巡る楽しみもゼロになりました。
その代わりランチはほぼ毎日自宅で自炊しているため、60分間という割と短い時間内に手早く調理できて、如何に美味しいものを作れるか、など、食材を考えたりする機会が増えました。まぁこれまで一番多かったメニューはそうめんですが(笑)
他にも、通勤時間が無くなったため、スマホに入れたアニメを見る時間もゼロになったり、幼稚園バスの朝晩の送り迎えは妻から私の担当に、毎日も掃除機も私。その代わり妻は勤務日数と時間を増やしてパートから契約社員になったり・・・と、家庭内もいろいろな変化が出始めています。
と、近況はともかく。。。
今回は、今担当している案件で必要になるかもしれない技術を検証しておこうと思います。
それは、AWS SSM(Systems Manager)を使って、VSS(Volume Shadowcopy)を使用したSnapShotを取得するというものです。
SQLのDBが動いているサーバに対して静止点をとってVSS Snapshotすることを目的としています。
DBはトランザクションが常に発生しているため、一般的に静止点を取らないと整合性の取れていないデータをバックアップすることとなってしまい、戻したときに整合性が取れていないため、矛盾のあるデータとして戻ってしまう可能性があるのです。その書き込みを一瞬止めてスナップショットを取得し、すぐにまた動かし始めるということを実行してくれるのが、WindowsのVSSの機能の一つなんです。
SSMについては勉強はしたので知識としてはあるのですが、実際に目的があって使うのは初めてなので、色々ググってみました・・・
ですが、AWSのページにもあまり丁寧に書いていない・・・そのため、色々なページを参考にして何とかできるところまでこぎつけた、という感じです。
#やったこと
やったことは以下の通り。
・Windowsのインスタンスを起動する
・既存ポリシーを適用したロールを作成する
・対象のインスタンスへロールを適用する
・SSMを開いてマネージドインスタンスを確認する
・だが、失敗する(マネージドインスタンスに出てこない)
・ロールの信頼関係にSSMを追加する
・SSMを開いてマネージドインスタンスを確認する(成功)
・SSMでRunCommandしてVSSコンポーネントをインストールする
・SSMでRunCommandしてスナップショットを作成する
・だが、失敗する
・不足していたポリシーをロールへ追加する
・やっとVSS Snapshotの取得が成功する
参考にしたのは主に以下のページです。
https://aws.amazon.com/jp/blogs/news/take-microsoft-vss-enabled-snapshots-using-amazon-ec2-systems-manager/
何をすればいいのか一覧になっていないため、あまり親切ではないですねぇ。
3~4つくらいの工程なのかな?と思っていたので、意外と結構長い道のりですね。
初めに軽く調べて実行しただけでは、まともに動きませんでした。
その理由や解決方法も含めて記載していきます。
まずは始めの一歩から行きましょう。
#準備編
##Windowsのインスタンスを起動する
今回はDBの動きも観察したいため、無料版SQLの入ったWindows2016を利用することにします。
「コミュニティAMI」の検索ワードは「2016 exp jap」としました。これで「Windows_Server-2016-Japanese-Full-SQL_2016_SP2_Express-(日付)」というイメージが見つかります。
また、SSMの利用時はSSMサービスへの通信が発生するので、パブリックサブネットにサーバを作成します。
もしプライベートサブネットで利用する場合には、別途SSMへのアクセスが可能なように、SSM用のVPCエンドポイントを作成したり、名前解決を可能にするなどの作業が別途必要だったりするそうですが、今回はとりあえずパブリックサブネットで行こうと思います。
##既存ポリシーを適用したロールを作成する
今度はロールの作成です。あまり慣れていないので、ポリシーとロールがごっちゃになってわけがわからなくなりますが、今回は作成したインスタンスに適用するロールを作成します。うん。ロールです。ロールケーキ食べたい。
ロールにはポリシーを適用する必要がありますが、今回必要になるポリシーは標準で用意されている「AmazonEC2RoleforSSM」というポリシーです。
IAMの画面の左ペインにあるロールをクリックし、「ロールの作成」を押します。
次に「一般的なユースケース」の下にある「EC2」をクリックしてから右下の「次のステップ: アクセス権限」を押します。
検索窓に「SSM」と入れると出てくる「AmazonEC2RoleforSSM」にチェックを入れてから右下の「次のステップ: タグ」を押します。
タグを入れたい場合には適当に入れて、右下の「次のステップ: 確認」を押します。
次のページではロールの名前をこちらも適当に入れて「ロールの作成」を押します。
はい!できました!
既にロールが適用されているインスタンスの場合には、そのロールに、上記のポリシーを追加して上げればOKです。
##対象のインスタンスへロールを適用する
ロールを適用しましょう。
インスタンスを選択し、「アクション」→「インスタンスの設定」→「IAMロールの割り当て/置換」です。
次の画面で、今作成したロールを選択し、右下の「適用」を押します。
出来ました!
##SSMを開く
さて、ここでSSMを開いて、左ペインから「マネージドインスタンス」を選択すると。。。
あ…あれれ??? はい。インスタンスがない場合にはこの画面が出ます(冷や汗)
そういえば、一つやることを忘れていました。
##ロールの信頼関係にSSMを追加する
もう一度ロールの設定に戻ります。
ロール名を押します。
「信頼関係」タブを押し、「信頼関係の編集」を押します。
でたー!コードの編集!
これ苦手なんですよねぇ。。。
でも今回は簡単です。
下記の黄色いところにカーソルを持ってきて、以下のソースをペーストすればOKです。(カンマから二行丸ごと)
"Service": "ssm.amazonaws.com"
以下のようになればOKです。右下の「信頼ポリシーの更新」を押します。
このように、信頼されたエンティティにSSMも出てくればOKです!
これで、もう一度、SSMのコンソールでマネージドインスタンスを見てみましょう。
これでも出てこなかったら、一度インスタンスを再起動したら出てくることもあるようです。
おー!再起動したら出てきました!
やったー!
#実行編
##SSMでRunCommandしてVSSコンポーネントをインストールする
さて、これで目的のインスタンスをマネージメントとできるようになったので、次はVSS Snapshotを取得できるように「AwsVssComponents」というコンポーネントを追加インストールします。
この作業は早速SSMで実行します。
SSMのコンソールから「Run Command」を開いて、右上にある「Run Command」を押します。
次の画面で「AWS-ConfigureAWSPackage」の左にある〇を押して選択します。
すると、画面の下に実行オプションが表示されます。
色々とコマンドのパラメーターはありますが、以下の様にコンポーネントの「Name」欄に「AwsVssComponents」とだけ記入しておけば、あとは空欄のままというか触らずにOKです。
次に、目的のインスタンスを指定しますが、これはもう「手動で選択する」で、今のところ一つしかないマネージドインスタンスにチェックを入れればOKです。
ここまでできれば、あとは右下の「実行」を押すだけです。ポチッ!と。
このように、「進行中」表示になり、しばらくしてリロードをすると、完了します。
はい!完了しました!成功です。
これで、VSS Snapshotの準備が整いました。
##SSMでRunCommandしてスナップショットを作成する
ついに準備が整ったので、VSS Snapshotの取得を実行してみます。
コンポーネントの追加と同じようにRun Commandから実施します。
画面右の「>」を押してページをめくると「AWSEC2-CreateVssSnapshot」が見つかりますので、その右のチェックを押します。
このパラメーターは特に必要な項目はありません。
紛らわしくなりそうなときは、Tagなどは入れたほうが良いかもしれませんね。
「Create AMI」で「True」を選択することで、AMIを作成することもできます。
インスタンスの指定も先ほどと同じです。
さあ!実行してみましょう!
##必要なポリシーをロールに追加する
とりあえず落ち着いてもう一度AWSのドキュメントを見てみます。
https://aws.amazon.com/jp/blogs/news/take-microsoft-vss-enabled-snapshots-using-amazon-ec2-systems-manager/
そういえばこの(↓)部分、スナップショットの実行を許可したりということはしていなかったですね。
もう一度ポリシーに戻って設定を追加してみましょう。
先ほど作成したロールに不足しているポリシーを追加すればいいのですが、既存のポリシーはディフォルトで存在している編集できないポリシーなので、新規で作成したポリシーを追加でアタッチすることにします。
まずはIAMからポリシーを選択し、「ポリシーの作成」、と。
EC2を選択します。
ここで、AWSのドキュメントにあった以下の3つを選択します。
DescribeInstances
CreateTags
CreateSnapshot
上記の3つを順番に検索窓へペーストして、チェックを入れていきます。
まずは「DescribeInstances」
次は「CreateTags」
最後は「CreateSnapshot」
(↑これ、複数形の方を選んだら動作にどう影響が出るのかめちゃくちゃ気になりますが、今はとりあえず無視して進めましょうか)
次は「リソース」を押して、「すべてのリソース」を選択し、右下の「ポリシーの確認」を押します。
適切な名前を付けて、右下の「ポリシーの作成」を押します。
出来ました。
さて、これを先ほどのロールへアタッチします。
作成したポリシーを選択し、「ポリシーの使用状況」タブを選択し、「アタッチ」を押します。
ポリシーのアタッチ画面になるので、先ほどのロール「TEST-SSM-ROLE」を検索してチャックを付け、右下の「ポリシーのアタッチ」を押します。
はい、アタッチできました!
さぁ、これでVSS Snapshotの実行権限はそろったはずです。もう一度トライ!
##再度SSMでRunCommandしてスナップショットを作成する
先ほどのSSMの画面を別のタブで開いていると、あらなんと便利なことでしょうか!「コマンドの再実行」とかいうボタンがあるじゃあ~りませんか!
さすがAWS、神ですね~
早速ポチッ!と。
「コマンドの再実行」!!!エイッ!
ドキドキ・・・
ドキドキ・・・
やったー!
取得出来ました!
EC2のSnapShotも確認してみたら、取得開始しています!成功!
#動作検証編
##OSのログで動作を確認する
念のため、Windowsのイベントログも見てみましょう。
なるほど、SnapShotの命令が出された直後にVSSサービスが「実行中」となっていますね。
さらに、Applicationも見てみると…
なるほど、「EC2VssSoftwareProvider」というイベントが発生して、SnapShotを取得している様子がわかりました。
さらに・・・
上のイベントから2秒後に「Snapshot successful」と来ています!
その間にMSSQLが「書き込みできません」というイベントも出ていますので、きちんと書き込みを抑制し、数秒以内にSnapShotを取得し終えていることがわかりました。