Serverless database synchronization

2016.09.30 JAWS-UG-KOBE Study meeting.
Microservice architecture ことはじめ。

Case study. synchronize 2 databases by using SNS, Lambda, Cloudwatch.

Transcript

1. Serverless database synchronization 2016.09.30 JAWS-UG-KOBE
2. Who am I? TiNm’S( ティムズ )と読みます。 プログラマー。 Ruby On Rails、AWSが主戦場。 好きなAWS サービスは、OpsWorks。 花澤香菜ちゃん好き。 JAWS-UG-KOBE の暴走運営。
3. 今回のお題 AWS上にある２つのデータベースの間のデータ連携を AWS lambda SNS CloudWatch イベントにより実現した事例を紹介します。
4. アジェンダ 背景 構成 デプロイ まとめ
5. 1. 背景
6. ※ MSSQLと学生さんが 作った顧客システム (１０年もの） スタッフ 同期 新しいWebサービスに古いデータを（一部） 同期する。
7. データベースをMySQLに一本化。
8. … のはずだった。
9. テーブルの数がシステムの割に 20個とか。(実際に使ってるのは３つのテーブルだけ )、カラムに備考1〜4まである。顧客IDと顧客コードという列がある、別に IDというidentity列もあったり、なかったりする。 ID列だけど、identityあったりなかったり、カラム数 40個もあるけど...、. 名前1,名前2ってなんだ！？、Isなんと か列多すぎない？全部判定に使ってる！？ 顧客名カラムにwifiのパスワード入ってるんですが。。。、ダイレクトメールのテーブルに、いつ送ったかだけあっ てもねえ。データの頭に ⭐ とかつけて、判断に使うのやめましょうよ。。郵便番号の形式が各テーブルでちがうのですが。（データ型からちがうってどゆこ と！？）、名前１はvarchar、名前2はnvarchar、どっちを使えばいいの？、いろんなテーブルにテンプレートっていう列があるんですが、しかもほとんど NULL なんですけどー。
10. ゾーンに入る 必要がありそうだ。 ….が、私はキ◦キの世代ではない....
11. 最低限だけ 同期することにした。
12. 2. 構成
13. fetch fetch pickup insert pickup insert 1time/day 1time/day MSSQL Feature : sync_mssql_to_mysql Feature : sync_mysql_to_mssql
14. ３つのlambda ファンクションと２つのSNSトピックデひとつの機 能(feature)を構成。 この固まりを機能レベルの単位とした。 それぞれの lambdaファンクションは、機能を実現するためのア クションとして定義する。 ( Ruby on Rails でいうところの、feature は Controller、各 lambda ファンクションはController Action をイメージすると考 えやすい。 )
15. 3. デプロイ
16. Lambda ファンクションがサービスの境界。 デプロイする際は、各 lambda ファンクションが 「疎」であることを最優先に考える。
17. 3.1 IAM Role を個別に適用
18. fetch pickup insert 1time/day lambda ファンクションのロールを共有する。
19. fetch pickup insert 1time/day MSSQL lambda ファンクションに個別のロールを適用する。
20. 3.2 IAM Role でリソースの制限
21. fetch pickup insert 1time/day アクセスしないリソースにも許可している。 Resource: [“*”] xxxx yyyy
22. fetch pickup insert 1time/day アクセスするリソースのみ許可している。 Resouce:[ “arn:aws:sns:ap-northeast-1:xxxxxxxxxx:yyyyyyyyy”] xxxx yyyy
23. 3.3 naming
24. 名前付けは(超)重要！！！ Lambda やSNSはそれぞれが個別のサービス。 複数のサービスを束ねて単位化しているので、この単位が明確にわかるよう各 サービスで使う要素に名前をつけていく。 そうしないと、各サービスのコンソールで表示したときにカオス化する。
25. fetch fetch pickup insert pickup insert 1time/day 1time/day MSSQL Feature : sync_mssql_to_mysql Feature : sync_mysql_to_mssql
26. lambda
27. SNS
28. 一つの方法として、各サービスのリソース名をfeature-action のかたちで名前をつけるという方法が 個人的にはわかりやすい。
29. 3.4 (余談) Lamveryとserverless
30. AWS にlambda(とその周辺サービス）をデプロイするツールと してserverless と lamvery いうツールがある。 どちらも、現状は一長一短があるという印象。 個人的な雑感を紹介しておきます。
31. Lamvery • Lambda をデプロイするには、使いやすいツール • virtualenvも作ってくれるので、外部ライブラリを合わせて使うのに便利 • API GatewayにAPIもデプロイできるが、lambda の実行ロール(execute-api)を 付与しないので、管理コンソールでlambdaは再適用する必要がある。 Python で Lambda のみデプロイするなら、オススメできる。
32. serverless • 1.0になって、APIのデプロイが非常にシンプルになった。 • APIGateway + lambda をある程度の既定の設定でデプロイするのに便利。 • 1.0になって、AWSのProfile指定ができなくなっているので、複数アカウントでデ プロイしたい場合、いちいちdefaultのプロファイルを切り替えたりしないといけな い。(issueあり） • 0.X では、CloudFormationのコードをゴリゴリかけたので、連携サービスもデプ ロイできた。1.0になってできなくなってる(...ぽい） シンプルにAPIGateway + lambda をデプロイするならオススメできる。
33. 個人的には、 規約ベースでデプロイするフレームワークが欲しい。 今回紹介した事例でいうと、feature と action と、action 間の連携を規約として定義 したら、SNSとlambdaとIAM Role を規約通りにデプロイする、といった感じ。
34. 4. まとめ
35. • Lambda ファンクション ごとにやることがはっきりしているので、モノリシックに 作ってたときありがちな、役割がぶれてくることがない） • Lambda ファンクションの単位でみれば、コードが少ないのでテストしやすい。 • 権限の変更が他のサービスに影響させないようRole作りは配慮が必要 • いろんなサービスと連携するので、名前付け超重要。 • (余談）ログの出力ルールをちゃんと決めておかないと、CloudWatchのログみた ときに死ぬ。
36. ありがとうございました。