Cloudflare対応してみた

特にこのサイトに負荷がある訳ではないけれどCloudflareを経由するように設定してみました。

ドメインはお名前で取得したものですのでこの辺の記事を参考にしてDNSの設定まで行って、直後にアクセスしても元の経路でしたが数時間後にみてみたらSSL証明書がCloudflareのものになっていたので、切り替わってるなあとわかりました。

あんまり早くなった気はしないが、、

追記

このQiitaの記事がなかなか良い。画像ファイルをCloud Strage使うのをやってないけど試してみようかな。

https://qiita.com/ryuta69/items/dbb0db5cf7099b7a7cc4

[AWS] SNSメッセージをSQSでサブスクライブする

マイクロサービス化する場合にモジュール間を疎結合に保つためコレオグラフィアーキテクチャを採用できるところではしたくなります。

コレオグラフィについてはQiitaの以下の記事が参考になります。

そこでpub/subの仕組みをどうやって実装するか?という課題ができてきますがAWSであればSNS/SQSが利用できます。
以下のスライドや記事が参考になります。


これで本番運用しよう!と思った時に1つ疑問が出てきました。
SNS->SQSとメッセージを送る際にSQSが障害などで利用できなくなっていた場合にSNSにパブリッシュされたメッセージはどうなるのか?まさか消えちゃうとか無いよね?と。

答えはFAQにありました。

Q: サブスクライブしているエンドポイントが利用できない場合、Amazon SNS メッセージはどうなりますか?

SNS に送信されたすべてのメッセージは、直ちに処理されて配信されます。最初の試行でメッセージが正常に配信されない場合、SNS では次の 4 段階の再試行ポリシーに従った処理が行われます。(1) 遅延なしの再試行、(2) 最小遅延間隔での再試行、(3) バックオフモデル (線形または指数的) を使用した再試行、(4) 最大遅延間隔での再試行です。
ポリシーはエンドポイントによって、以下のように異なります。

SQS: SQS キューが利用できない場合、SNS は直ちに 10 回、続いて 20 秒間隔で 100,000 回の再試行を行います。つまり 23 日あまりで合計 100,010 回の再試行が行われます。この再試行後に配信されないメッセージは SNS から破棄されます。

SQSへの送信が失敗した場合のメッセージの消失については23日間障害が続くというのは考えにくいですし、十分にリトライ処理がされるようなのであまり気にしなくても大丈夫そうです。

とはいえ、SQSが利用できない間はサービスが利用できない状態になると復旧までにかかる時間によっては何か考えないといけないです。
全リージョンで同時に障害というのはあまりないのでマルチリージョンで構築するというのも1つのやり方のようですがどの程度まで担保するかは要検討。

DDDを実践するときのアーキテクチャ

エリックエバンス本や実践ドメイン駆動を読んでも思想的なところは定義されているものの実際のプロジェクトの中でどう落とし込むのかについては、それぞれで考えないといけないです。

DDDと一緒に語られているアーキテクチャについてよくまとまっている記事がQiitaにあったので参考に。

今、進行中の案件ではKotlinでSpringBootを使ってバックエンドのAPIを開発していて、
普通にやるといわゆるMVCの三層アーキテクチャになってしまうのですがここにドメインモデル層を確立してドメインロジックを集約したいなと思っています。

Controller -> Presentation
Service -> Application

思想的なところでのマッピングとしてここまではよくて、
ドメインモデルとORマッパー実装を切り離しドメインモデル層を確立しないといけないです。
ORマッパーはMyBatisを採用しています。
model層にはモデルとMapperのinterfaceを定義しinfrastracture層にMyBatisに特化した実装を逃しています。

以下のようなinterfaceをmoodel層に定義し、

infrastracture層には以下を定義します。

Couponモデルに値オブジェクトとしてCouponCodeを定義していたり、Couponのビジネスロジックを集約するようにします。

こんな感じで三層アーキテクチャ+ドメインモデルを試みておりますがまだまだ色々と試行錯誤を繰り返しています。

DDDを開発現場に落とし込む

Webアプリの開発現場において、Spring Bootを使っていわゆるMVCの三層モデルで構築してきました。
最近流行りのドメインモデルをきちんと理解してオブジェクト思考で開発することのメリットを最大限に生かしたいなと。

DDD本といえばまずはこの2冊。
“エリック・エヴァンスのドメイン駆動設計”

“実践ドメイン駆動設計”

実践ドメイン駆動設計の方がより具体的にイメージがしやすいので読みやすいが、それでもなかなか理解するのが難しい部分も多い。

そこで合わせて読みたいなと思ったのがこちら。
“現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法”

一見、DDD本には見えない題名ですが、ドメインモデルを駆使した設計の話が全体で説明されており、難解なDDD本の理解を助けてくれるものと思いました。
これだけを読むというよりはこの本を読み進めつつ、”実践ドメイン駆動設計”の該当する章も参照するなどすると理解が深まると思います。

最近、読んだ本では結構オススメです。

AWS API Gateway & Microservices on ECS

こういう構成のシステムを構築したいのだけどAPI Gatewayで認証をかけてもALBをpublicにしないといけないとかでそれも考慮が必要。
良いやり方がないか色々と試行錯誤をしてようやく1つできそうな方法を思いついたけれどこれがベストなのか不明。

figure1

今回、認証したいのはエンドユーザではなくAPIを利用するサーバ。
IP制限とかできれば良いのだけれど、それは難しいという要件。

その方法というのは以下の通り。
1. APIを利用するサーバはCognitoからtokenを取得
2. そのtokenをHTTPヘッダに付与してAPIをリクエスト
3. APIサーバ側ではそのトークン(JWT)の署名検証を行う

これをnginxのモジュールとして実装するか、Webアプリ側のfilterとして実装する想定。

イメージ図

署名検証用のlambda
https://github.com/awslabs/aws-support-tools/blob/master/Cognito/decode-verify-jwt/decode-verify-jwt.py

署名検証用のlambda functionの呼び出しサンプル

参考にした資料

Amazon Web Services パターン別構築・運用ガイド 改訂第2版 (Informatics&IDEA)

新品価格
¥3,672から
(2018/7/16 22:10時点)

AWSの支払いを日本円でできる

実は2015年からできるらしい。
Amazon Web Servicesブログに 2017-10-18 に記事が投稿されてました。
この記事を見るまで知らなかった。。。

合格対策 AWS認定ソリューションアーキテクト – アソシエイト

新品価格
¥2,376から
(2017/11/1 13:10時点)

Amazon Web Services パターン別構築・運用ガイド 一番大切な知識と技術が身につく

新品価格
¥5,598から
(2017/11/1 13:11時点)

IntelliJ IDEAでプロパティファイルを編集/閲覧する

Eclipseを使っている時はプラグインをインストールする必要があって、どのプラグインがいいの?って感じでしたが
Intellijはデフォルトでできるんですね。
はじめに開いたら読めない感じだったのでプラグインを入れないといけないのかと思いましたけども。

IntelliJ IDEAハンズオン――基本操作からプロジェクト管理までマスター

新品価格
¥2,894から
(2017/11/1 00:54時点)

SpringBoot+MyBatis+Kotlinでの実装

SpringBootがKotlinをサポートしているのでサーバサイドの実装をKotlinでやりたいなと思って色々と調査中。

普通にRESTful APIを実装するにはREST Controllerを利用して書けるのでJavaを利用するときと比べて違和感もなく、少し便利な書き方もできるなという印象。


さて、次はDB周り。
既存の案件でMyBatisを利用しているものが多い感じなのでMyBatisを使おうかなと。

Kotlinで書くことでMapperとか書きやすくなるけれどもモデルを自動生成したいなあ。
Javaで生成してKotlinから参照すればいいのかなあ。
なんかいい方法があれば教えて欲しいと思っているところ。。

Kotlin Webアプリケーション 新しいサーバサイドプログラミング

新品価格
¥3,240から
(2017/10/30 10:32時点)