2017-06-08

サーバーレスシングルページアプリケーションを監訳しました

Serverless

サーバーレスを活用したシステムが普及していく中で、国内で知見がどう素早く大量に共有されるべきか考え、昨年からサーバーレスのコミュニティやイベント開催で場を作ってきました。その流れの1つとして本の執筆・翻訳・監訳もやりたいなと考えておりましたら、昨年読んで実践して非常に分かりやすかった「Serverless Single Page Apps」を監訳する機会をいただきました。

www.oreilly.co.jp

6/23に紙の本がオライリーやAmazon、また街の本屋さんで買えるようになる他、オライリー・ジャパンのEbook Storeで PDF販売 も開始されるそうです。

目次を見ていただくとおわかりのとおり、非常にシンプルな構成になっており、1章から8章まで順に読み進めながら手を動かすことでサーバーレスでSPAが一式出来上がるようになっています。

この本の特徴を3つほど挙げておきます。

2章から順にアプリを作っていくことになりますが、実際に手を動かす場面ではいちいち「なぜこうするのか」が説明されているので、理解が追いつかないまま進んでいくことが少ないのではないかと思います。
SPAで利用するIDフェデレーションやデータベースなど、アプリに連結して利用するコンポーネントサービスに関してはローカル環境でエミュレートするような方法は使わず、ローカルのコードからクラウド上のコンポーネントサービスを使うようになっているので、開発のための環境準備がとても少なく済みます。
アプリケーション側のコードを書く前にテストコードを書いてテストし、ビューのルートを追加してテストし、ロジックを記述してテストするというテストドリブンなアプローチで作成していくため、どこまで動いていてどこを変えたら動かなくなったかというようなデバッグが簡単にできます。

ということで、基本をしっかりと押さえて開発を進めるにあたり便利な一冊だと思いますのでぜひ手に取ってみてください。

逆にこの本のスコープではない「ReactやVue.jsといったjQuery以外のJavascriptフレームワーク」「Jasmine以外のテストフレームワーク」「アプリ全体の完全なローカル環境構築」「チーム開発のワークフローのベストプラクティス」「ユースケースやデプロイ先のステージ管理に便利なサーバーレス用の管理フレームワーク」「AWS以外のコンポーネントサービスの利用」のあたりはこの本の先の知見ということで、ぜひ皆さんの開発現場での知見を積み上げて共有していただけると助かります。

読んだ人たちの反応

Twitter や Facebook でいただいた反応

6/23に発売のサーバーレスシングルページアプリケーションを監訳者の @yoshidashingo さんからご恵贈いただきました。これは楽しい！ pic.twitter.com/tmHZe1v0nx
— Ryutaro YOSHIBA (@ryuzee) 2017年6月19日

いただきました。手を動かしながら全体的に学ぶのにちょうど良さそうな雰囲気。ありがとうございます！！ @yoshidashingo pic.twitter.com/aUsOA7V3Rw
— Masashi Terui (@marcy_terui) 2017年6月19日

サーバーレスSPA本がどれだけやばいかを端的に紹介すると、p7で早速「サーバーレスデザインの最初で最大の制限は、アイデンティティプロバイダをサポートしたWebサービスを使う必要があること」というパワーフレーズが登場。そうそうそれなんだよー！！！！！！
— Aki＠めもおきば (@nekoruri) 2017年6月18日

f:id:yoshidashingo:20170627124633p:plain

f:id:yoshidashingo:20170627124648p:plain

f:id:yoshidashingo:20170627124651p:plain

「サーバーレスシングルページアプリケーション」に書いてあるこの一文がすごい気に入った -- "設計のまずいモノリシックなシステムが「大きな泥だんご」なら、設計のまずいマイクロサービスシステムは「アリの大群」でしょう。どちらも日曜日の午後に裏庭で見つけたくはありません。"
— YutakaKato.jar 🐽 (@kagaorange) 2017年6月29日

『サーバーレスシングルページアプリケーション』のチュートリアルを、手を動かしながら遊んでいる。たのしい。
— たーせる (@tercel_s) 2017年6月30日

WEBサイトを作ったことがある/ない関係なしのおすすめ本情報

サーバーレスシングルページアプリケーション ―S3、AWS Lambda、API Gateway、DynamoDB、Cognitoで構築するスケーラブルなWebサービス https://t.co/0F0dqsJ0EJ
— バトルプログラマー柴田智也🔄🍣 (@tomoya_shibata) 2017年7月5日

2017-05-18

Serverlessconf Austin のビデオ

Serverless

セクションナインの吉田真吾（@yoshidashingo）です。

先月のServerlessconf Austinの動画が上がったようです。

個人的な見どころ

Nodeはサーバーレス(イベントドリブンなプラットフォーム)向けの言語じゃないという話
サーバーレスラップ
百貨店なのにサーバーレスをガンガン使っているNordstromのアーキテクチャ変遷
事例山盛りなLambda
多機能(多接続)化が顕著なAzure Functions+Logic Apps
実は日本の事例であるTrek10のServerless GraphQLの話
マルチベンダーのFunctionの共有、検索、実行ができるstdlibというプラットフォーム
オープン化でオンプレでもBlueMixでもとにかく面で導入を押し進めるOpenWhisk
開発者に大人気なFirebase

などなど...ぜひ見てみてください。

www.youtube.com

2017-05-09

DMSを使って非暗号化RDS MySQLから暗号化Auroraに無停止で移行する

AWS AWS-移行

セクションナインの吉田真吾（@yoshidashingo）です。

DB無停止移行は人類の夢
- 利用する特徴
手順
まとめ
- 参考

DB無停止移行は人類の夢

暗号化していないRDS MySQLから暗号化済みのAuroraに移行したいけど、スナップショットの復元でもAurora Read Replicaのマスター昇格でも一発ではリソース暗号化ができませんが、そんなときに便利なのがDatabase Migration Service(DMS)です。

DMSを使えばどちらかがリソース暗号化されたデータベースであってもフルデータロード＋継続レプリケーションができます。

今回はDMSからの接続に必要な移行元のbinlogのフォーマットを変えずに（DMSでレプリケーションできないDBが移行元であっても）レプリケーションするために、間にAurora Replicaを用いて実装してみます。

f:id:yoshidashingo:20170509204051p:plain

利用する特徴

Aurora Read Replicaはbinlog_formatがROWでないRDS MySQLから簡単に継続レプリケーションできる
DMSは非暗号化<->暗号化データベース間の読み書きをサポートしている
DMSのターゲットデータベースのロジカルレプリケーションはターゲットへの書き込みもできる

少しAWSに覚えのある方であればこの特徴だけでどうやればよいかわかると思うので、後は読まなくても大丈夫です、これを組み合せることで無停止で移行します。

手順

説明用の3種類のデータベースインスタンス名は以下のような名前になっています。

移行元データベース(MySQL) mydbinstance
中間データベース(DMSのソースデータベース: Aurora) mydbinstance2
移行先データベース(DMSのターゲットデータベース: Aurora) mydbinstance3

移行元データベース(MySQL)

移行元のRDS MySQLではデフォルトのパラメータグループを作成している想定です。

f:id:yoshidashingo:20170509210044p:plain

バックアップは1日以上（今回の場合は2日）設定されているものとします。ストレージ暗号化はされていないので、この状態からでは暗号化済みのAuroraに一発で移行することはできません。

f:id:yoshidashingo:20170509210535j:plain

中間データベース(Aurora Read Replica)

CDCを利用した継続レプリケーションを行うために、移行元のRDS MySQLのAurora Read Replicaを作成します。

Auroraのbinlogからレプリケーションを有効にするためにDBクラスターパラメータグループの設定変更をします。デフォルトのものは設定変更ができないので、あらかじめ新規にDBクラスターパラメーターグループを作成して以下の値を変更しておき、Aurora Read Replicaの作成時にこれを適用してインスタンスを作成します。

binlog_checksum NONE
binlog_format ROW

f:id:yoshidashingo:20170509211020p:plain

また、mysqlクライアントで接続し、binlogの保持期間の変更を行っておきます。エラーでレプリケーションが止まっても十分に対応できる程度の時間にしておきましょう。今回は12時間に設定しておきました。

mysql> CALL mysql.rds_set_configuration('binlog retention hours', 12);

移行先データベース(暗号化済みAurora)

移行先は(せっかくの機会なので)暗号化しときましょう。デフォルトのDBクラスターパラメータグループだと後で設定を返るときに不便ですが今回は無視します。こちらのbinlogは今回不要です。

f:id:yoshidashingo:20170509212314j:plain

DMS

適当なサイズでDMSインスタンスを作っておきます。

ちなみにこの状態だとMySQLとAurora Read Replicaのテーブルにはデータが入ってますが、ターゲットにはデータが入っていない状態になります（上から1号機／2号機／3号機）

f:id:yoshidashingo:20170509213904p:plain

ソース／ターゲットデータベースに接続する

f:id:yoshidashingo:20170509212944p:plain

タスクを作成して実行する

対象のスキーマを指定してマイグレーションタスクを投入します。マイグレーションタイプには初期データのフルロードと継続レプリケーションを選択しましょう。

f:id:yoshidashingo:20170509213302p:plain

このタスクを実行すると、フルデータロードされてターゲットにもデータが同期されます。

f:id:yoshidashingo:20170509214019p:plain

このタイミング、あるいはフルデータロード後に一時停止しておいて一度「Analyze Table」しておきましょう。

継続レプリされているか確認する

もう一行挿入して継続レプリされているか確認しましょう。

f:id:yoshidashingo:20170509214311p:plain

アプリ切替

移行元ではなくターゲットに直接データを書き込んでみましょう。

f:id:yoshidashingo:20170509214636p:plain

ターゲットにのみデータが書き込まれました。

移行元にデータを書き込む

この状態で一部のトランザクションが移行元側に入ってしまっても、ターゲットにまで伝搬するので問題ありません。

f:id:yoshidashingo:20170509215125p:plain

よって、複数のアプリの切替が必要な場合でも、このレプリケーションが継続レプリケーションを行い始めた後であれば、それぞれ任意のタイミングで切替が可能になりうるということが分かります。

まとめ

手順を見れば分かるとおり、同一レコードへのトランザクションが移行元／移行先に別々に入ってしまう場合や、Auto Increment属性が付与されているテーブルに移行元／移行先に別々に入ってしまう場合などについての考慮は必要になりますが、そういう条件が発生しえない場面においては、レプリケーションを切り離すタイミングとアプリの切替を同期する必要がなくなるのは嬉しい方法ではないかと思います。

また、統計情報の再作成のためのAnalyze Tableのタイミングについては今回適当に継続レプリケーション中に行いましたが、実際はターゲットデータベースにかかるワークロードを考慮したタイミングを精査しておく必要があると思います。実際DMSではフルデータロード後で継続レプリケーションを開始する直前に一時停止させることができるので、そのタイミングでAnalyzeさせることも可能です。

また、データベースの移行・切替は非常にセンシティブな作業ですので、実際に作業する時は事前に十分な検証したうえで実行しましょう。