sorta kinda...

主にAWS関連ですが、これに限らずいろいろ勉強したことや思ったことを書いていきます。

SSM でコマンド実行できるかどうか確認するコマンド [cloudpack OSAKA blog]

ナスです。

前回、SSM でコマンド実行するための IAM ロールについて書きました。今回は、GUI で確認してたことを aws cli でやってみただけの記事です。これ知ってるだけで確認時間短縮になりますので、忘れずに書き残してこうと思います。

 

ドキュメント

ドキュメントにも記載があります。前回の記事でも紹介したトラブルシューティングのドキュメントです。 docs.aws.amazon.com

 

試したコマンド

オンラインになっている EC2 インスタンスの情報を表示するコマンドです。もうこれだけで十分な気がしています。

$ aws ssm describe-instance-information --instance-information-filter-list key=PingStatus,valueSet=Online
{
    "InstanceInformationList": [
        {
            "IsLatestVersion": true,
            "ComputerName": "ip-172-31-31-244.ap-northeast-1.compute.internal",
            "PingStatus": "Online",
            "InstanceId": "i-********************",
            "IPAddress": "172.31.31.244",
            "ResourceType": "EC2Instance",
            "AgentVersion": "2.0.847.0",
            "PlatformVersion": "2016.09",
            "PlatformName": "Amazon Linux AMI",
            "PlatformType": "Linux",
            "LastPingDateTime": 1499692626.203
        },
        {
            "IsLatestVersion": false,
            "ComputerName": "WIN-43V67ICDPJJ.WORKGROUP",
            "PingStatus": "Online",
            "InstanceId": "i-********************",
            "IPAddress": "172.31.17.78",
            "ResourceType": "EC2Instance",
            "AgentVersion": "2.0.805.0",
            "PlatformVersion": "6.3.9600",
            "PlatformName": "Microsoft Windows Server 2012 R2 Standard",
            "PlatformType": "Windows",
            "LastPingDateTime": 1499692626.651
        }
    ]
}

AWS 管理コンソールでも確認すると、確かに 2 台オンラインになっていますね。 f:id:nasrinjp1:20170710223046p:plain

 

ちなみに、全台オフラインだとこんな結果になります。

$ aws ssm describe-instance-information --instance-information-filter-list key=PingStatus,valueSet=Online
{
    "InstanceInformationList": []
}

 

SSM でコマンド実行前にこういったコマンドで状況を確認することで、後続のスクリプトでエラーになる可能性を減らせる場面もあるかと思います(実際ここまで確認する場面があるかどうかは不明…)ので、積極的に aws cli を使っていきましょう。

既存 EC2 インスタンスに IAM ロールをつけて気になったこと [cloudpack OSAKA blog]

ナスです。

結構前の話ですが、起動済みの EC2 インスタンスに IAM ロールをつけたり、別の IAM ロールに付け替えたりできるようになりました。これのおかげで、かなり前に作成した EC2 インスタンスにも SSM でコマンド実行できるようになりましたね。

で、実際にやってみたんですが、ちょっと気になる点があったので、まとめて書いておきます。

 

IAM ロールの権限が反映されるまでの時間がなんか長い

そのままなんですが、IAM ロールがついていない EC2 インスタンスにロールをつけて、すぐに SSM でなんかコマンド実行しようとしたら、この状態でした… f:id:nasrinjp1:20170710131117p:plain

あれ? SSM の権限つけたはずなのに…

トラブルシューティングのドキュメントをみても、エージェントが動いているかどうかと、IAM ロールに必要な権限がついているかどうかを確認する旨の記載しかありません。 docs.aws.amazon.com

と、調べているうちに、気がついたら実行対象として選択できるようになっていました。 f:id:nasrinjp1:20170710132144p:plain

 

OS によって IAM ロールをつけた後のタイムラグの長さが違う

実際には条件は同じかもしれませんが、なんとなくそんな気がしています。自分の検証環境でテストしてみたところ、↓のような結果が出ました。

起動中の EC2 インスタンスの IAM ロールを変えてほったらかして、SSM の画面で表示されるまで

起動中の EC2 インスタンスの IAM ロールを変えて再起動した場合

  • OS に関係なく即反映

 

雰囲気ですが、Linux だとわりと早く IAM ロールの内容が反映されて、Windows だとちょっと時間がかかる、と言う感じです。

私は IAM ロールを変更して反映されなかったらすぐに元に戻して調べていたのでこのことになかなか気づきませんでしたが、もし同じようなことで悩んでいる方がいたら、きっと反映されるので気長にそのままにして待ってみてください。もし再起動できる環境なら再起動してみましょう。きっと幸せが訪れますよ。

DB を AWS に移行する [cloudpack OSAKA blog]

ナスです。

最近、DB を AWS に移行する話がちょくちょく出てきているので、ここらでどれくらい簡単に DB 移行できるのかをご紹介したいと思います。

 

移行の目的

他のエントリでも書いたような気がしますが、何度でも書きますね。なぜそのシステムを移行するのか?を明確にしましょう。テスト移行して AWS に移行するメリットを探るとか、本当にコストが下がるかどうかをシミュレーションしたいからとか、この課題を解決したいからとか、いろいろあると思います。

 

移行の流れ

以前にも紹介しましたが、移行の流れは大きく6パターンあります。
medium.com

一番多いパターンが、Rehost ですね。ひとまず AWS にシステムを移行してから、その後 AWS をうまく活用して業務の効率化や改善を進める流れが多いです。

DB に関して言えば、もう OS や RDBMS を管理したくないから RDS を使いたい、なんて要望もあったります。その場合には、ツールを使って DB データだけを RDS に移行することを検討しましょう。今回の記事では、RDS に DB データを移行する流れを取り上げます。

 

移行手法

どうやって移行するのか?というのがエンジニアの方の一番の関心ではないでしょうか?(違う?

AWS では、DMS (Database Migration Service) というサービスがあります。これを使うだけで、オンプレミスの DB データを簡単に AWS (RDS) に移行することができるんです。このサービスはエージェントが不要で、移行先の VPC に移行用のインスタンスを立てて、そこから移行元と移行先に対して DB 接続するだけで移行準備が完了します。後は AWS 管理コンソールからボタンをポチポチするだけで移行ができてしまいます。いやー楽ですね!(実際はいろいろな制約等があってなかなか大変なんですけどね…

 

移行イメージ

では簡単に DMS を使って DB 移行する流れをささっとご紹介しましょう。AWS 管理コンソールにログインして、DMS の画面で新規タスク作成のウィザードを開始するまでは、頑張ってやってみてくださいね。

まずは移行用インスタンスを作成します。名前や設置する VPC を指定していきます。 f:id:nasrinjp1:20170628223856p:plain

次に移行元と移行先の DB に接続するための情報を入力します。入れたらそれぞれ最後にテストするのを忘れずに。今回は Oracle DB を例にしますね。 f:id:nasrinjp1:20170628223922p:plain

移行タスク設定です。移行実行時に移行先のテーブルをどうするか、LOB はどう扱うかを指定していきます。 f:id:nasrinjp1:20170628223941p:plain

最後にテーブルマッピング設定です。ここでは、MASTER スキーマの全テーブルを移行するよう指定しました。必要に応じて不要なテーブル等は Exclude の条件を追加していってください。 f:id:nasrinjp1:20170628224005p:plain

さて、移行設定は終わりました! ステータスが準備完了になったら、開始ボタンを押して移行を始めます。 f:id:nasrinjp1:20170628224025p:plain

ステータスがロード完了になれば移行完了です。今回は 100 万レコードを持つ TBL1 テーブルしかなかったのですぐに終わりました。 f:id:nasrinjp1:20170628224044p:plain

移行の詳細は、CloudWatch Logs に残りますので、エラー等が発生すればここでチェックできます。 f:id:nasrinjp1:20170628224058p:plain

 

実際はもっと大規模&大量のデータを移行することになるので、こんなに簡単にはいきませんが、これまでの移行手法と比べるとダウンタイムもかなり短くできますし、何より人の手があまりかかりません(エラーがない前提ですが…)

テスト的に移行するだけならダウンタイムは0なので、ちょっと気になるなーって方は是非トライしてみてくださいね!