sorta kinda...

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

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

AWS Database RDS Migration

ナスです。

最近、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

　

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

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

Windows Server のパフォーマンスモニターの情報を CloudWatch に投げる [cloudpack OSAKA blog]

AWS CloudWatch Windows Monitoring

ナスです。

CloudWatch 便利ですね。勝手に CPU とかの情報を取ってきて閾値超えたらアラート上げてくれるので、ちょっとした監視ならこれで十分です。ただ、そんな便利な CloudWatch も万能ではありません。メモリの情報もデフォルトでは取れないので、ちょっと設定してあげる必要があります。

今回は CloudWatch にメモリ情報を投げる手順をご紹介します。メモリに限らず、パフォーマンスモニターで見れる情報ならなんでも CloudWatch に投げられるので、それなりに参考になると思います。

ただ、そのまんまやったらつまづくことがあるので、ハマったポイントを重点的に書いていきます。

　

ドキュメントはこれ

全体的な設定の流れはこのドキュメントの通りです。 docs.aws.amazon.com

　

選んだ方法

Systems Manager Run Command を使いました。選んだ理由は↓です。

  • OS にログインしなくてもいい（設定は全部 AWS コンソールからできる）
  • 複数のインスタンスに対して同時にできる
  • 「CloudWatch のインスタンスを設定する」ページの一番上に書いてあったから（推奨なのかな？と勝手に思った）

　

ハマったポイント 1

IAM ロールを対象の EC2 インスタンスにつけるのですが、どんなポリシーにすればいいのかわかりづらかったです。結局 AmazonEC2RoleforSSM だけアタッチした IAM ロールを EC2 インスタンスにつけただけでよかったです。

　

ハマったポイント 2

AWS.EC2.Windows.CloudWatch.json をダウンロードして編集します。が、このドキュメントの通りにやっただけではうまくいきません。なぜかというと、対象の Windows Server インスタンスで取れない情報を取ろうとするからです。カスタムログとか。

なので、今回は CloudWatch に投げない項目の設定は全部削除しました。必要最低限の設定だけにした JSON が↓です。使用可能メモリ量とページング使用率だけ取る例です。今回は最小限にしましたが、このファイルにはデフォルトでイベントログや任意のログファイルのメッセージを CloudWatch Logs に投げる定義も書かれているので、対象のファイルのパス等を正しく定義してやればメッセージも投げられますよ。

{
    "IsEnabled": true,
    "EngineConfiguration": {
        "PollInterval": "00:00:15",
        "Components": [
            {
                "Id": "PerformanceCounterMemory",
                "FullName": "AWS.EC2.Windows.CloudWatch.PerformanceCounterComponent.PerformanceCounterInputComponent,AWS.EC2.Windows.CloudWatch",
                "Parameters": {
                    "CategoryName": "Memory",
                    "CounterName": "Available MBytes",
                    "InstanceName": "",
                    "MetricName": "Memory",
                    "Unit": "Megabytes",
                    "DimensionName": "InstanceId",
                    "DimensionValue": "{instance_id}"
                }
            },
            {
                "Id": "PerformanceCounterPaging",
                "FullName": "AWS.EC2.Windows.CloudWatch.PerformanceCounterComponent.PerformanceCounterInputComponent,AWS.EC2.Windows.CloudWatch",
                "Parameters": {
                    "CategoryName": "Paging File",
                    "CounterName": "% Usage",
                    "InstanceName": "_Total",
                    "MetricName": "Paging",
                    "Unit": "Megabytes",
                    "DimensionName": "InstanceId",
                    "DimensionValue": "{instance_id}"
                }
            },
            {
                "Id": "CloudWatchLogs",
                "FullName": "AWS.EC2.Windows.CloudWatch.CloudWatchLogsOutput,AWS.EC2.Windows.CloudWatch",
                "Parameters": {
                    "AccessKey": "",
                    "SecretKey": "",
                    "Region": "us-east-1",
                    "LogGroup": "Default-Log-Group",
                    "LogStream": "{instance_id}"
                }
            },
            {
                "Id": "CloudWatch",
                "FullName": "AWS.EC2.Windows.CloudWatch.CloudWatch.CloudWatchOutputComponent,AWS.EC2.Windows.CloudWatch",
                "Parameters":
                {
                    "AccessKey": "",
                    "SecretKey": "",
                    "Region": "ap-northeast-1",
                    "NameSpace": "nasu/test"
                }
            }
        ],
        "Flows": {
            "Flows":
            [
                "(PerformanceCounterMemory,PerformanceCounterPaging),CloudWatch"
            ]
        }
    }
}

　

結果

NameSpace で指定した名前空間が、CloudWatch メトリクスに出てきます。 f:id:nasrinjp1:20170606184223p:plain

中身を見てみると、ちゃんと JSON で定義した項目だけが出てきています。メモリ情報なので、グラフ自体は全く面白くないですね。 f:id:nasrinjp1:20170606184347p:plain

　

いろんな監視システムやサービスがありますが、自前でわざわざ準備＆管理するのが面倒なら、こんな感じで CloudWatch を使ってみてはいかがでしょうか。