光るりんご

これはアップルが学生向けのプロモーション動画の中の1シーン。

どうやら2016年のモデルチェンジ以降は鏡面仕様の現在のりんごマークになっている様子。最新モデルの機能をアピールしたりするような内容ではないのでモデルはなんでも良いという判断なのかな?

鍵を探すTile Mate

明けましておめでとうございます。

2019年が始まりました。
今年の4/1には新年号が発表となり5/1に改元となりますし、10月には消費税増税が待っているという変化の年となりそうです。

さて、Amazonが初売りセールをしていたので眺めていてTile Mateという製品を買っちゃいました。

スマートトラッカーという言われるもので家の中でどこに行ったかわからなくなったものを音を鳴らして探せるというものです。

Apple WatchでiPhoneを探すのもちょいちょい使っているのですが、もう一つよくなくすのが家のカギです。カバンや上着のポケットに入れっぱなしにしてしまいどこにしまったのかわからなくなってしまうのでカギに付けました。

これで今年はカギを探している時間を節約できるハズ。

Google PayがQUICPay対応でKyashも利用可能に

iPhoneではApplePay対応が進みませんが。。
KyashのApplePay対応は誤報

Google PayがQUICPayに対応しKyashも利用できるようです。

ワリカンなどで回収したKyashの残高をリアル店舗で使いやすくなるのは素晴らしい。

iPhoneではOrigamiPayにKyashのカードを登録することでローソンなんかで利用できることを最近知りました。
キャッシュバックの還元率も良いみたいなのでLINE Payみたいにキャッシュバックがなくなる前に試しておくのが良いかもですね。

[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つのやり方のようですがどの程度まで担保するかは要検討。

VPNサービスと動画配信サイト

先日、タイにいってきました。
その際にJリーグの試合の観戦をしたくてHotspotVPNを利用して日本サーバから接続してみましたが観ることはできませんでした。
以前はこの方法で海外から接続できたことがあったのですが。。ついでにスカパーオンデマンドもダメでした。

おそらく有名どころのVPNサービスが利用しているIPアドレスをブラックリスト化しているのかなと思われますが利用者側からすると残念です。
海外での配信権を持っていないからということだと思うので実際VPNを利用してもみられないのがサービス提供者としては正しい状況です。

ゲームや動画配信の権利って音楽に比べると全世界で提供できるようなライセンスを取得するのが難しいものなのですかねえ?
そもそもサービス提供者がコンテンツごとの配信料を視聴数とかで従量で権利者に支払うような契約ができるなら再生された分だけきちんと権利者に支払いがされて、視聴を制限するよりもみんな得すると思うのですけどそうも行かない事情があるのかな。

コンテンツを持っている人にきちんと利益を配分しつつ、ユーザが利用しやすいようになるといいなあと思ったのでした。

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本の理解を助けてくれるものと思いました。
これだけを読むというよりはこの本を読み進めつつ、”実践ドメイン駆動設計”の該当する章も参照するなどすると理解が深まると思います。

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

Dash Buttonの新規登録ができない

以前にミネラルウォーターと洗濯用洗剤のDash Buttonを買って使っています。

つい先日、オールフリーのDash Buttonを購入しました。これです。

オールフリー Dash Button

新品価格

¥500から
(2018/7/16 22:39時点)

最近は炭酸水やオールフリーなどのノンアルコールビールにはまっています。
暑くなってきたのでオールフリーを切らさないように購入しました。

以前にもDash Buttonは設定したことあったので何気なく設定を始めたのですがなんかエラーが出て設定が完了できません。。

たまたまかなと思って、端末を再起動したりルータの再起動したりしながら10回くらい試してみましたが全然解決できません。
そこでサポートにチャットお問い合わせをしてみました。

始めは普通のトラブルシューティングを案内されます。
1、 Dash Buttonがお使いのスマートフォンの近くにあること
2、Wi-Fiネットワークの接続範囲内であること
3、Dash Buttonのセットアップ時に使用したAmazonアカウントで Amazonショッピングアプリにサインインしていること

また、「他のスマートフォンを使用して、再度接続を試していただけますでしょうか。」ということで手元の他のiPhoneでやってみましたがだめ。

そうするとサポートは言いました。

上記のトラブルシューティングを行って問題が改善できなっかたので、恐らくネットワークの不具合可能性が高いです。
お客様はプロバイダーまたはネットワーク管理者にお問い合わせいただけますようお願い申し上げます。

ん?なんとネットワークの問題!
いやいや、他の機器は同じネットワークで問題なくインターネットに接続できているし、別のダッシュボタンは動いてますよ、と伝えたところ別の部署へエスカレーションされました。

そちらの担当者いわく

お調べしましたところ、お客様は、Amazon.comのアカウントと結合されていることがわかりました。
大変申し上げにくいのですが、アカウントを結合されている場合、Dash Buttonの登録ができない問題が発生しております。

きたーー
またこの問題ですね。

また「調査中ではございますが、長期間未解決の状況でして、今すぐに解決することが難しい状況です。」とのことで解決の目処が立っていない模様。

ということで返金手続きを取ることになりました。

“Amazon.comのアカウントと結合” しているユーザはダッシュボタンの新規導入はできない状況のようです。
ヘルプや購入ページにそういった記載は一切ありませんでした(2018-07-16現在)ので該当する方は気をつけましょう!

追記
Wifi設定だけでもできていれば別の用途に使えるかな?と思ったけれどできなそうだった。
macアドレスが拾えない。。

サントリー オールフリー 350ml×24本 ノンアルコールビールテイスト飲料

新品価格

¥2,299から
(2018/7/16 22:38時点)

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時点)