[ESP-IDF]Google Home

詳細. 1.構想. クラウドとしては、. IFTTTでGoogleアシスタントチャンネルをトリガ、Webhooksチャンネルをアクションとする; Webhooksチャンネルでは、AWSのAPI Gatewayで作ったエンドポイントをたたく; API GatewayからLambda関数を呼び出す; Lambdaで、リクエスト内容に応じて、AWS IoTにトピックをパブリッシュする. 続きを読む

S3、AWS Lambda、API Gateway、DynamoDB

サーバーレスシングルページアプリケーション : S3、AWS Lambda、API Gateway、DynamoDB、Cognitoで構築するスケーラブルなWebサービス. 資料種別: 図書; 責任表示: Ben Rady著 ; 笹井崇司訳; 言語: 日本語; 出版情報: 東京 : オライリー・ジャパン東京 : オーム社 (発売), 2017.6; 形態: xxv, 204p ; 24cm; 著者名:. 続きを読む

1ヶ月でAWS 認定ソリューションアーキテクトに合格した話

昨年(2017年)の8月にAWS 認定ソリューションアーキテクト – アソシエイトに合格しました。
ほぼゼロからの勉強でしたが、要点を抑えれば短期間でも合格できたので、やったことを紹介します。

1. 前提知識

趣味で触ったことがあるもの。※どれも軽く触った程度

  • EC2
  • ELB
  • S3
  • Lambda (試験には出ない)
  • API Gateway (試験には出ない)

2. 対策内容

2-1. AWS Summit Tokyo 2017 セッション資料・動画

オススメ度: ★★★★★

一番オススメです。
「試験範囲の動画を見る → 実際にAWS上でやってみる」で大体雰囲気つかめました。
各サービスの「入門」だけで十分だと思います。
(話すペースがゆっくりなので、1.5倍速ぐらいで見ないと眠くなります。)

2-2. AWS Black Belt

オススメ度: ★★★★☆

安定の公式資料集です。
そこそこボリュームあるので、自分は理解の浅いサービスに絞って読みました。
(試験範囲の資料は一通り目を通した方が良いのかも?)

2-3. 参考書

オススメ度: ★★★☆☆

唯一の対策本なので、読んでおいて損はないと思います。
ただ情報量は少なめなので、概要をつかむ程度に使いました。

オススメ度: ★★☆☆☆

ハンズオン形式で進めるので、イメージがつきやすいです。
ただこちらも情報量としては足りてないので、合わせて他の対策も必要です。

2-4. AWS WEB問題集

オススメ度: ★★★☆☆

無料枠のみ解きました。
本番と似たような問題が出題されるので、そこそこ参考になります。
(何問かは本番とまったく同じ問題でした。運が良かっただけかも?)

3-5. それっぽい構成で作ってみる

オススメ度: ★★★★☆

ある程度理解が進んだら、サービスを複数組み合わせて何か作ってみるのがオススメです。
自分の場合は以下の構成で、Hello Worldをブラウザから表示するぐらいの簡単なものを作りました。

 VPC + ELB + EC2 + AutoScaling + CloudWatch + Route53

3. 結果

正答率(模擬試験): 75%
正答率(実試験): 72%

試験当日は、そこそこ感触が良かったのですが、思ったより点数が伸びず^^;
何はともあれ、一発合格できて一安心でした。

4. 感想

  • 実際に手を動かすことが一番タメになりました。やってみないとわからないことがけっこうあります。
  • ある程度知識が付いた段階で、模擬試験を受けることがオススメです。雰囲気つかめます。
  • セキュリティグループとネットワークACLに関する問題が多く出題された気がします。
  • とにかく試験会場が暑かった。。。

続きを読む

Serverless FrameworkでAPI Gatewayバイナリサポートを設定する

API Gatewayでバイナリを扱いたい場合、バイナリサポートを有効にする設定が必要になります。
その設定をServerless Frameworkで定義しました。

ServerlessFrameworkのデフォルトではバイナリサポートの設定パラメータが用意されていないためプラグインを使用します。

調べたところ現時点では以下の2つのプラグインが見つかりました。

一つ目のserverless-apigw-binaryは試してみたときに、デプロイは成功していてもAPI Gatewayに反映されていないということがあったため、二つ目のserverless-plugin-custom-binaryを使うことにしました。

環境

$ npm -v
5.5.1

$ serverless -v
1.22.0

設定方法

プラグインのインストール

$ npm install --save-dev serverless-plugin-custom-binary

設定を追加

serverless.yml
plugins:
  - serverless-plugin-custom-binary

custom:
  apigatewayBinary:
    types:
      - multipart/form-data

デプロイ! :beer:

$ serverless deploy

デプロイ完了後、API Gatewayのコンソールで確認するとちゃんと設定されています。
スクリーンショット 2018-02-03 22.20.23.png

以上です。

続きを読む

初めてのAWS Lambda(どんな環境で動いているのかみてみた)

月曜日から3日間、AWSアーキテクト研修でした。そこではじめてLambdaに接しまして、ひととおり驚いてきたところです。自分なりのまとめです(ご存知の方には釈迦に説法)。

Lambdaとは?

恥ずかしながら私は「サーバーレス」という言葉を聞いてもいまいちピンと来ていませんでした。ですが、これは文字通りなんですよね。プログラムが動作する環境なんてどうだっていいんです。OSがなんだとか、ミドルウェアがなんだとか、メモリがどれくらいでCPUがいくらで、NWがどうで、トポロジーがなんでとか、そんなことはどうでもいいんです。
とにかく、「トリガー」と呼ばれる”きっかけ”を契機に、コード(プログラム)が動くんです。JavaならJVMがおもむろに立ち上がって、アップロードしておいたjarが実行されるんです。「トリガー」はAWSサービスと高度に統合されていて、例えば

  • ファイルストレージサービスであるところのS3(もはや単なるストレージの域を超越していますが)にファイルがアップロードされた
  • メッセージがキューにputされた
  • API Gatewayにリクエストがきた
  • EC2インスタンスが起動した
  • 3時になった
  • おなかがすいた(とAmazon echoに話した)
  • e.t.c.

MDBならぬTDB(Trigger Driven Bean)でしょうか。Beanである必要もないので、TBC(Trigger Driven Code)とでも言ったほうがいいのかもしれません。

うごかしてみる

研修の間、実習時間に余裕があったので、研修端末に入っていたEclipseで簡単なコードを書いて動かしてみました。テストはAWS Consoleからキックできるので、特に「トリガー」を定義しなくても動かすだけなら簡単に試せます。

お作法

基本的にどんなJavaプログラムでも必要なライブラリを組み込んでおけば動きますが、コールするメソッドにはお約束があるようです。それは引数です。第一引数にObjectをもらい、第二引数にContextをもらいます。メソッド名はなんでもいいです。型もなんでもいいです(ただし第一引数と戻り値の型ともにSeriarizableである必要あり。プリミティブ型もOK)。

第一引数に入るのは、具体的には「トリガー」からの情報です。メッセージがキューにputされたことをトリガーとするのであれば、そのメッセージ自体を渡してあげたり。戻り値は同期呼び出しであればほぼそのまんまでしょう。インタフェース要件に従って、Serializeして返してあげればよいだけです。

第二引数のContextですが、これはjavax.naming.Contextではなく、com.amazonaws.services.lambda.runtime.Contextです。というわけで、AWSが提供するjarファイルをビルドパスに追加する必要があります。1

作る

まだ意味のあるコードを書くほどの技量もアイディアもないので、インフラ屋っぽくどんな環境(システムプロパティ、環境変数、渡されたContextオブジェクト)で動いているのかみてみることにしました。

SystemInfo.class
package net.mognet.aws.lambda;

import java.util.Map;
import java.util.Properties;

import com.amazonaws.services.lambda.runtime.Context;

public class SystemInfo {

    public static String printSystemInfo(int i, Context context) {
            StringBuilder sb = new StringBuilder();
            //ヘッダを追加
            sb.append("name,value\n");

            //システムプロパティ取得
            Properties prop = System.getProperties();
            for(Object key : prop.keySet()) {
                String name = (String) key;
                String value  = prop.getProperty(name);
                sb.append(name + "," + value + "\n");
            }
            //環境変数取得
            Map<String, String> env = System.getenv();
            for(String key : env.keySet()) {
                String value = env.get(key);
                sb.append(key + "," + value + "\n");
            }
            //Contextの情報を取得
            sb.append("context" + "," + context.toString());
            return sb.toString();
    }

    public static void main(String[] args) {
            System.out.println(printSystemInfo(1, null));
    }
}

mainはテスト用です。1個目の引数こそ本来は大事なんでしょうけど今回は何もしません。

乗せる

AWSコンソールを開いてLambdaの関数を作ります(関数という単位で動きます。複数の関数をオーケストレーションするサービスもあるようです(詳細未調査))。
スクリーンショット 2018-01-31 21.39.16.png
適当に名前とランタイム(今回はJava8)を選んで「関数の作成」を押します。
標準出力はCloudWatchLogsへ流れるので、事前にCloudWatchLogsへのWrite権限のあるロールを作って必要に応じてここでアタッチしてください。
スクリーンショット 2018-01-31 21.39.50.png
スクリーンショット 2018-01-31 21.39.57.png
本来ならここでトリガーを選んで云々となりますが、とにかくテストしてみたいだけなので、その辺の条件だけいれます。
スクリーンショット 2018-01-31 21.40.05.png
関数コードのところで、「アップロード」からjarファイルをアップロード、大事なのが「ハンドラ」でここに実行するメソッドを入力します。書き方が決まっていて、”.”表記でクラスのフルパスの後ろに”::“をつけてメソッド名です。
今回は”net.mognet.aws.lambda.SystemInfo::printSystemInfo“となります。ついでに環境変数もつけてみました。一旦「保存」すると実際にファイルがアップロードされます。
スクリーンショット 2018-01-31 21.41.03.png
次にテストの準備です。テストケース(入力設定=第一引数設定)です。画面上部の「テストイベントの設定」を選びます。
スクリーンショット 2018-01-31 21.41.19.png
実行するメソッドpublic static String printSystemInfoの第一引数がintなので、1とだけ書いて終わりです。下の方にある「保存」を押します。これでテスト準備完了です。

いざ実行!

おもむろに「テスト」を押します。
スクリーンショット 2018-01-31 21.42.15.png
動きました。今回はログ出力(標準出力)なしなので、ログは見ませんが開始と終了のメッセージが出ていました。String型のメソッドを実行したので、returnした文字列がそのまま画面上に表示されています(改行コードは改行してほしかったけど実行結果表示コンソールとしてはこれが正しいあり方ですね)。

付録

付録で実行結果を載せておきます。

name value
java.runtime.name OpenJDK Runtime Environment
sun.boot.library.path /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.141-1.b16.32.amzn1.x86_64/jre/lib/amd64
java.vm.version 25.141-b16
java.vm.vendor Oracle Corporation
java.vendor.url http://java.oracle.com/
path.separator :
java.vm.name OpenJDK 64-Bit Server VM
file.encoding.pkg sun.io
user.country US
sun.java.launcher SUN_STANDARD
sun.os.patch.level unknown
java.vm.specification.name Java Virtual Machine Specification
user.dir /
java.runtime.version 1.8.0_141-b16
java.awt.graphicsenv sun.awt.X11GraphicsEnvironment
java.endorsed.dirs /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.141-1.b16.32.amzn1.x86_64/jre/lib/endorsed
os.arch amd64
java.io.tmpdir /tmp
line.separator
java.vm.specification.vendor Oracle Corporation
os.name Linux
sun.jnu.encoding UTF-8
java.library.path /lib64:/usr/lib64:/var/runtime:/var/runtime/lib:/var/task:/var/task/lib:/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib
java.specification.name Java Platform API Specification
java.class.version 52.0
sun.management.compiler HotSpot 64-Bit Tiered Compilers
os.version 4.9.77-31.58.amzn1.x86_64
user.home /home/sbx_user1066
user.timezone UTC
java.awt.printerjob sun.print.PSPrinterJob
file.encoding UTF-8
java.specification.version 1.8
java.class.path /var/runtime/lib/LambdaJavaRTEntry-1.0.jar
user.name sbx_user1066
java.vm.specification.version 1.8
sun.java.command /var/runtime/lib/LambdaJavaRTEntry-1.0.jar
java.home /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.141-1.b16.32.amzn1.x86_64/jre
sun.arch.data.model 64
user.language en
java.specification.vendor Oracle Corporation
awt.toolkit sun.awt.X11.XToolkit
java.vm.info mixed mode, sharing
java.version 1.8.0_141
java.ext.dirs /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.141-1.b16.32.amzn1.x86_64/jre/lib/ext:/usr/java/packages/lib/ext
sun.boot.class.path /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.141-1.b16.32.amzn1.x86_64/jre/lib/resources.jar:/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.141-1.b16.32.amzn1.x86_64/jre/lib/rt.jar:/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.141-1.b16.32.amzn1.x86_64/jre/lib/sunrsasign.jar:/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.141-1.b16.32.amzn1.x86_64/jre/lib/jsse.jar:/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.141-1.b16.32.amzn1.x86_64/jre/lib/jce.jar:/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.141-1.b16.32.amzn1.x86_64/jre/lib/charsets.jar:/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.141-1.b16.32.amzn1.x86_64/jre/lib/jfr.jar:/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.141-1.b16.32.amzn1.x86_64/jre/classes
java.vendor Oracle Corporation
file.separator /
java.vendor.url.bug http://bugreport.sun.com/bugreport/
sun.io.unicode.encoding UnicodeLittle
sun.cpu.endian little
sun.cpu.isalist
PATH /usr/local/bin:/usr/bin/:/bin
AWS_XRAY_DAEMONADDRESS 169.254.79.2
LAMBDA_TASK_ROOT /var/task
AWS_LAMBDA_FUNCTION_MEMORY_SIZE 128
TZ :UTC
AWS_SECRET_ACCESS_KEY secret
AWS_EXECUTION_ENV AWS_Lambda_java8
AWS_DEFAULT_REGION ap-northeast-1
AWS_LAMBDA_LOG_GROUP_NAME /aws/lambda/SystemInfo
XFILESEARCHPATH /usr/dt/app-defaults/%L/Dt
_HANDLER net.mognet.aws.lambda.SystemInfo::printSystemInfo
LANG en_US.UTF-8
LAMBDA_RUNTIME_DIR /var/runtime
AWS_SESSION_TOKEN tokenString
AWS_ACCESS_KEY_ID accessKeyId
LD_LIBRARY_PATH /lib64:/usr/lib64:/var/runtime:/var/runtime/lib:/var/task:/var/task/lib
X_AMZN_TRACEID Root=1-5a71b98c-393aaa7b51f5612a348586c0;Parent=3ff8164301e3ccd4;Sampled=0
AWS_SECRET_KEY secretKey
hogehoge gehogeho
AWS_REGION ap-northeast-1
AWS_LAMBDA_LOG_STREAM_NAME 2018/01/31/[$LATEST]29640ec0ac8e426ab2b0a041b3a1b1f4
AWS_XRAY_DAEMON_ADDRESS 169.254.79.2:2000
AWS_XRAY_DAEMONPORT 2000
NLSPATH /usr/dt/lib/nls/msg/%L/%N.cat
AWS_XRAY_CONTEXT_MISSING LOG_ERROR
AWS_LAMBDA_FUNCTION_VERSION $LATEST
AWS_ACCESS_KEY accessKey
AWS_LAMBDA_FUNCTION_NAME SystemInfo
context lambdainternal.api.LambdaContext@604ed9f0

アクセスキー等の情報も環境変数に乗っていましたのでそこはマスクしてます。そういう仕様だということは理解しておくべきかもしれません。この辺のキーを使ってAWS API呼び出したりするのかな?あと、ちゃんと設定した環境変数も出て来てます(あたりまえですが)。
OpenJDK on Amazon Linuxで動かしているみたいですね。こればっかりは実際に本稼働したときにどうなるかわかりませんけれども。あくまでこのテスト実行時はこうでした、というだけです。なんといってもサーバーレスですので、繰り返しになりますが実行環境(HW、OS、MW等々)はどうでもいいです。というか、どうでもいい前提でコードを書いてください、というのがLambda的な使い方と認識しました。

参考

Lambda 関数ハンドラー(Java) – AWS Lambda


  1. EclipseにはAWSのツールキットプラグインがあるので、この環境をセットアップしておくだけでも可です。 

続きを読む

AWS DDoS対策勉強まとめ

・DDOS攻撃
複数の攻撃元が協調して大量のパケットやリクエストを送ってサービスを停止させる

・ランサムDDoS
攻撃者が公開サーバーをいつでも停止できる

下記三軸で考える
【高さ】
レイヤーごと
– アプリケーション層攻撃
アプリケーションリソースを攻撃。
HTTPGET

DNSクエリフロッド
→ボットネットと呼ばれる複数の感染ホストを利用し、大量のクエリをDNSに配信

  • 状態枯渇攻撃
    ファイヤーウォールなどに攻撃
    TCP SYNフロッド
    →クライアントから意図的にACKを返さないことで、他のユーザがアクセス出来なくする
  • ボリューム攻撃
    処理できる能力を越えたトラフィックを送る
    UDP反射攻撃
    →攻撃者はIPを偽装。要求と応答のパケットのサイズ差を利用

【深さ】
アプリケーションごとに対策は違う。
→エッジとリージョンなど

・ウェブアプリケーションの場合
エッジでAWS WAF, CloudFrontを利用
リージョンでセキュリティグループで対策

・クライアント/サーバーアプリケーションの場合
EC2の垂直スケール、拡張ネットワークでトラフィック吸収

・ゲームアプリケーションの場合
Routing Matching ServiceでIP配布
特定のIPのみからアクセスするよう制御

【幅】
・地理的分散
→CloudFrontで配信分散

・攻撃対象隠蔽
→セキュリティグループ使用
→Amazon API Gatewayを利用。Web API公開サーバーを立てない
→ELBでEC2を見せない

・攻撃吸収、緩和
→AWS Shieldによる自動緩和システム
→CloudFrontによるGEOリストリクション
→Route53。高可用性
→ELBとAutoscalingでインスタンスそp増減
→拡張ネットワーク。NICへのアクセスを複数あるようにする

・計画、監視
→CloudWatchでの監視

・AWS Shield Standard
Layer 3/4 protection
→一般的な攻撃から防御
無料

Layer 7 protection
→WAFを利用
→使った分だけ支払い

・AWS Shield Advanced
Standardに加え、より大規模な攻撃からの防御

参考URL:
https://www.slideshare.net/mobile/AmazonWebServicesJapan/20170905-aws-blackbeltddosmitigation-79478348

続きを読む

AWS Lambda+API Gateway + S3で格安リアルタイム画像リサイズAPIを作成する

こんにちは、シンクロ・フードの大久保です。 今回は実際に弊社で運用しているAWS Lambdaを使ったリアルタイム画像変換APIについてご紹介したいと思います。 リアルタイム画像変換APIについては、あまり詳しく説明しませんが、画像のサイズ変換等をURLパラメータで指定してリアルタイムに変換することです。 弊社の場合 … 続きを読む

AWS DMSを使ってRDS for PostgresからDynamoDBにデータ移行

はじめに

Postgresqlに保存してあったデータをDynamoDBに移行させるために、AWSのDMS(Database Migration Service)を使ってみた時の、メモをまとめた記事である。

背景

クローリングしたデータをRDS for Postgresqlに保存していて、そのデータの利用してAPI GatewayとLambdaを使ってAPIサーバを作成しようと思っていたのだが、RDSとLambdaは相性が良くないということが判明した(接続数の問題などで)。
しかも、DynamoDBを使えば、エンドポイントがつくられるので、わざわざLambdaで関数作る必要無いことに気がついたので、RDS to DynamoDBへの移行計画を立てることにした。

調べているとAWS DMSという、いかにもなサービスがあったので使ってみることにしたというのが、事の顛末である。

AWS DMSについて

AWS DMS(Database Migration Service)は、Databaseの移行を簡単に行えるサービスである。
Mysql to Mysqlのような同種DB間のデータ移行にも当然対応しているが、Postgresql to DynamoDBのような異種DB間のデータ移行にも対応している。
利用シーンとしては、オンプレのMySQLサーバをRDS for MySQLに移行する際や、RDS for PostgresqlをAurora for Postgresqlに移行する際に使用する。
また、一度だけのデータ移行にも使えるが、継続的なレプリケーションにも対応しているので、開発/テスト環境の同期などにも使うことができる。
ちなみに、Aurora、Redshift、DynamoDBに移行する場合はDMSを6ヶ月間無料で使うことができる。今回はDynamoDBに移行させるので、試すにはピッタリだった。

移行手順

1. レプリケーションインスタンスの作成

DMSでデータ移行するためにはレプリケーション用のインスタンスを作成する必要がある。
これは、DMSの設定画面から簡単に設定できる。

AWSコンソールから
「Database Migration Service >> レプリケーションインスタンス >> レプリケーションインスタンスの作成」
を選択。

すると以下のような画面が出てくる。
image.png

  • 名前:

    • レプリケーションインスタンスの名前
  • 説明:
    • レプリケーションインスタンスの説明
  • インスタンスクラス:
    • EC2でいうインスタンスタイプ
    • 2018年1月現在ではt2とc4インスタンスが選べる
    • 料金はこちら
  • レプリケーションエンジンのバージョン:
    • バージョン2.4.0を選択するとデータの検証ができるらしい
    • 古いものを選ぶ理由は今のところ無いので新しいバージョンを選ぶ
  • vpc:
    • レプリケーションインスタンスを置くvpc
    • 移行元か移行先どちらかのvpcに置くと色々と楽
      • ちなみに、移行元か移行先のどちらかがAWSサービスでないとDMSは使用できない
  • マルチAZ:
    • レプリケーションインスタンスをマルチAZ配置にする場合有効にする
  • パブリックアクセス可能:
    • レプリケーションインスタンスをインターネットアクセス可能にする場合有効にする
    • VPCでサブネットやインターネットゲートウェイをしっかりと設定しているのであれば有効にする必要がない(はず)

2. ソースエンドポイントの作成

ソースエンドポイントでは移行元のDBへのアクセス方法を設定する。
今回はRDS for Postgresqlが移行元DBになる。

AWSコンソールから
「Database Migration Service >> エンドポイント >> エンドポイントの作成」
を選択。

すると以下のような画面が出てくる
image.png

  • エンドポイントタイプ:

    • ソースかターゲットを選択
    • 移行元がソースなので、ここではソースを選択
  • エンドポイント識別子:
    • 作成するエンドポイントの名前
    • 同じ名前のエンドポイントは作成できない
    • 名前が同じでなければなんでも良い
  • ソースエンジン:
    • 移行元のデータベースエンジン
    • 今回はPostgresqlなので、postgesを選択
  • サーバ名:
    • 移行元のサーバ名
    • オンプレの場合であれば、そのサーバのアドレス
    • RDSであれば、インスタンスのエンドポイントを入力すれば良い
  • ポート:
    • 移行元DBのポート番号
    • 今回はPostgresのデフォルトポートの5432を入力
  • SSLモード:
    • 移行時の通信を暗号化するかを選択する
    • SSLを有効にした場合には、安全にはなるがオーバーヘッドが増えるので必要化判断して有効化すること
    • 選択した項目によりサーバ証明書が必要になる
    • 選択項目は以下の4つ
      • none: 暗号化しない
      • require: 暗号化される。証明書は不要。
      • verify-ca: 暗号化される。証明書が必要。
      • verify-full: 暗号化される。証明書とサーバのホスト名が一致するか確認される
  • ユーザ名
    • 移行元DBのユーザー名
    • ここでマスターユーザを選択しないと色々と面倒なので、マスターユーザを選択すること
  • パスワード
    • 先程選択したユーザのパスワード
    • 「&」や「+」のような記号はエスケープしないと使えない
    • 「&」や「+」が入る場合は全てを波括弧「{}」で括ること
  • データベース名
    • 移行したいデータベース名

一通りの設定をした後、接続テストができる。
ここで接続する元は、先程作成したレプリケーションインスタンスになるため、セキュリティーグループやファイアーウォールでアクセス制限をしている場合は、レプリケーションインスタンスがアクセスできるようにする必要がある。

3. ターゲットエンドポイントの作成

こちらでは移行先のDBのアクセス方法を設定する。
今回の移行先はDynamoDBになる。

設定方法は基本的にソースエンドポイントと同じだが、ターゲットエンドポイントにDynamoDBを設定した場合には、サービスのアクセスロールだけ指定すれば簡単に設定することができる。

AWSコンソールから
「Database Migration Service >> エンドポイント >> エンドポイントの作成」
を選択。

エンドポイントタイプをターゲットを選択し、ターゲットエンジンをDynamoDBにすると、以下のような画面が出てくる。
image.png

  • エンドポイント識別子:

    • エンドポイントの名前
    • 既に作成済みのエンドポイントと重複しなければ良い
  • ターゲットエンジン:
    • 移行先のデータベース
    • 今回はdynamodbを選択
  • サービスへのアクセスロールのARN
    • DynamoDBのアクセス権限があるIAM RoleのARN
    • ポリシーは細かく設定できるけど、めんどくさかったので以下のポリシーをアタッチ
      • AmazonDynamoDBFullAccess
      • AmazonDMSVPCManagementRole(いらないかも…?)

これも、必ず接続テストを行うこと。
DynamoDBに関しては、設定したロールが正しいアクセス権限を持っていれば問題なく接続できる(はず)

4. タスクの作成

移行するための最後の設定としてタスクを作成する。

AWSコンソールから
「Database Migration Service >> タスク >> タスクの作成」
を選択。

すると以下のような画面が出てくる。タスクの設定だけはちょっと長いので分割して説明する。
image.png

  • タスク名:

    • タスクの名前
    • これはなんでも良い
  • レプリケーションインスタンス:
    • このタスクで使用するレプリケーションインスタンス
    • 今回は 1. で作成したものを使用する
  • ソースエンドポイント:
    • このタスクの移行元となるエンドポイント
    • 今回は 2. で作成したものを使用する
  • ターゲットエンドポイント:
    • このタスクの移行先となるエンドポイント
    • 今回は 3. で作成したものを使用する
  • 移行タイプ:
    • このタスクで継続的にデータのレプリケーションを行うか設定する
    • 項目は以下の3つ
      • 既存のデータを移行する

        • 初回の移行のみ実行する
      • 既存のデータを移行し、継続的な変更をレプリケートする
        • 初回の移行を実行し、その後も継続的にレプリケートされる
      • データ変更のみをレプリケートする
        • データ変更のみをレプリケートされる
        • 通常、同種DB間の移行にのみ適用されるらしい
        • どういう時に使うかはよくわからなかった
    • 今回は、一度だけ移行ができれば良いので、「既存のデータを移行する」を選択
  • 作成時にタスクを実行
    • タスクの作成と同時にタスクを実行したければチェックをつける

次はタスク設定の画面
image.png

  • ターゲットテーブル作成モード:

    • タスク実行時に移行先のテーブルをどうするかを設定する
    • 設定項目は以下の3つ
      • 何もしない

        • 移行先にテーブルがない場合作られる
      • ターゲット上のテーブルをDROP
        • 移行先のテーブルを全部DROPする
      • TRUNCATE
        • メタデータに影響を与えないよう、TRUNCATEされる
  • レプリケーションにLOB列を含める:
    • データ移行の際にLOB(Large Object)を含めるか設定する
    • 画像をバイナリで保存している際などに、そのデータを移行するか設定する
    • 以下の設定項目がある
      • LOB列を含めない

        • LOB列を移行対象から外す
      • 完全LOBモード
        • サイズに関係なくLOB列を移行対象に含める
        • チャンク単位で送信するため、低速
      • 制限付きLOBモード
        • 次で設定する最大LOBサイズ以上のデータを削除して送信する
        • 完全LOBモードに比べると高速
  • 最大LOBサイズ(KB):
    • レプリケーションにLOB列を含めるに制限付きLOBモードを選択した時の最大LOBサイズ
  • 検証の有効化:
    • 移行元と移行先でデータを比較し検証するかどうかを選択する
  • ロギングの有効化:
    • 移行時のログをCloudWatch Logsに吐くかを選択する

最後にテーブルマッピングの設定
image.png

  • 選択ルールを設定する。
  • このルールに基いて、除外するテーブルやカラムを決定する。
  • ワイルドカードを使用できるので、まぁまぁ柔軟に設定できそう。
  • 最低一つは設定しなければいけないっぽい。
  • 一旦、デフォルトの状態のまま選択ルールの追加する。
  • 選択ルールを一つでも追加すると、変換ルールも追加できるようになる。
    • 名前の変更とか、テーブルや列の削除しかできないので、結構限定的。

以上が全て設定できたら、タスクの作成ボタンを押下。
「作成時にタスクを開始」にチェックが入っている場合にはすぐにタスクが実行される。

所感

実際にAWS DMSを使ってみて、かなり簡単に異種DB間のデータ移行を実現することができた。
データ量もあまり多くなかったため、10分程度で全てのデータ移行が完了していた。
コストも今回は無料だったし、実際に課金されても低コストで使用することができそう。

実際にDynamoDBを見てみるとPostgresqlにあったテーブルが作成されていた。
しかし、いくつかカラムが消えていたので、まだ調査が必要そうだ(LOB列と判断された…?)。

参考

続きを読む

タイムテーブル|AWS Lambda実践講座2018[ 2018年3月1日(木)・ 2018年3月9日(金)(全2回)]

19:00~21:00(120分). AWS Lambda実践授業の前のPC持参環境の説明/ガイダンス. Lambda開発者カウントの作成; Lambda実行ルールの作成/Lambda開発マシンの準備/AWS CLIの準備; IAMユーザーの作成、作成したIAMユーザーのログイン; API Gateway、SES・SQS、SNSを操作する権限; IAMロールの作成; S3/ … 続きを読む