kdnakt blog

hello there.

続・ #AWSDevDay Tokyo 2018 で色々学んだ話とか

AWS イベントレポート

1日目と3日目、それぞれ午後から参加してきた！
ということで3日目の感想を。

お品書き。

　

[3日目(11/2)の感想ツイート]

　
　

[3日目(11/2)に視聴した講演]

　

マイクロサービス時代の認証と認可 / 都元ダイスケ氏

www.slideshare.net

アムロ声です、とのアイスブレイクから始まった。気になって集中できない（笑）
コンポーネント間の認証とかも重要ですよね、その辺を話しますとのこと。マイクロフロントエンドの話も、少しあとの講演があるので大筋はそちらに譲るが多少話す、と。
　
認証と認可の違い、など基礎的な話から。ある程度わかっているつもりの部分だったけれど、改めて説明しろと言われると難しいな、と思ったけど、大変わかりやすい説明だった。
　
リクエスト署名といえば、ということで、AWS APIのリクエスト署名の話も少し。署名バージョン1については、脆弱性があるので使ってはいけない、とのこと。知らなかった。情報あるかなと思ったけれど、軽くググった程度では、すでにサポートされていない、という以外の情報は得られなかった。
　
ユーザーの認証とシステムの認証の違い、気をつける点について。データが誰のものか、というと（本発表のケースでは）消費者のものであり、事業者が再委託的に預かっているにすぎない、そのため、ユーザーの許諾が必要か否か、という点が重要になるとのこと。その話を聞いて思い出したのは、2018年11月現在ではあまり話題に上がらなくなったが、半年前はやたらと騒がれていたGDPRのこと。あれも、データ管理者とデータ処理者で考慮すべき点が違っていて、似たような話かな、と思った。
　
SSO（シングルサインオン）に関する話題が出たので、認可をどのように実装していくか、についても話が出るかな、と思ったけれど講演中には詳しいお話は伺えなかった。
ありがたいことに、セッション後のAsk the Speakerでその点について質問させていただくことができた。スピーカの都元さんはJava屋なのでJavaの場合なら、Spring Securityなどのフレームワークを利用して、ユーザーの認証情報を管理する認証MSAを立てて実現することができる、とのこと。もう少し踏み込んだ話をしたかったけれど、あまり時間がなかったので残念。
　
最後の方、SLO（シングルログアウト）は闇、と。意識したことなかったけど、確かに難しそう……。
　
　

Backends For Frontends 入門 / 古川陽介氏

　
Node.jsのコラボレータでもある古川さんのお話。
　
BFFのユースケース5つの紹介から。
恥ずかしい話、この辺は2018年春の技術書典4で買った『Microservices architecture よろず本』でちらっと読んだ程度で、複雑な連続するAPIコールをネットワーク等のリソースが貧弱なMobileクライアントの代わりに実行しHTMLレンダリングないしJSON生成を代替するもの、というイメージしか持っていなかった。（『よろず本』が悪いという話ではなく、私が理解していないというだけです、念のため。続編も出ている良書ですよ！）

booth.pm ota42y.booth.pm

本セッションでは、5つのユースケースとして、API Aggregation, Session Management, Server Side Rendering, File Upload, WebSocket/LongPolling/ServerSentEventが挙げられていた。思った以上にいろんな用途があるんだな、と認識を改めることができた。
　
Netflixのケーススタディが面白かった。PCからカーナビとデバイスが多岐にわたるためデバイスごとのAPIを実装していたがスケールしないため、ClientAdaptorCodeという呼称で自然発生的にBFFが実現されていった、と。やはり必要に応じて適切なパターンを実装していくのが良くて、最初からそこ（だけ）を目指す、というのは悪手な気がするなあ……（自戒）。 　
自社でも実践されているとのことで、アンチパターンの紹介があったのがよかった。チーム間のコミュニケーション問題、インフラ・レスポンシビリティ問題、ビッグバン・ジョイント問題など。それぞれ、自作のツールなどを含めて解決していっているという話が聞けた。
チーム間コミュニケーション問題は、これからまさにハマるような気がしているので、気をつけたいところ……。
　
　

Micro Frontends の理論と実践 -価値提供を高速化する真のマイクロサービスのあり方- / 澤井宣彦氏

　
理論＝課題は何か、どういう技術で解決するか、実践＝得られた知見や課題など、の話。
　
フロントエンドは結合レイヤなので、必然的に密結合になってしまっており、マイクロサービスの恩恵を受けづらいという問題がある、と。で、それを解決するためにiframeが使われていたり、WebComponentsが使われていたりする、と。
WebComponentsは前述の『よろず本』でも（たしか）そこまで細かく取り扱われていなかったので、window.customElements.define()とかの実装方法が勉強になった。
　
実践編の課題については、cache bustingとかグローバル状態共有とか、ブラウザ間差異とか、なんとなくフロントエンドの問題と言われてイメージのつくものだった。法人のお客様の場合はIE11が重要で……という話が出てきた時には優しい気持ちになれたものの、ReactとShadow DOMの組み合わせで上手くいかないことがあると聞いて、やっぱりフロントエンド辛いな、という気持ちになった。
　 あまり触れられていなかったような気がするけれど、結局結合レイヤは残っているようだったし、そのあたりの最後のモノリスとの戦いが今後どのように進展していくのか楽しみでもある。 　
　

Building and Running Microservices with AWS / 篠原英治氏

　
AWSのソリューション・アーキテクトの方のお話。
資料は今のところなし。
　
Amazon.comでマイクロサービスがどのように考えられ、作られてきたか。AWS上でユーザーによってどのように実践されてきたか。そして開発者がどうしていくと良いか。といった内容が語られた。
が、内容もさることながら、講演中ほぼ一貫して、「マイクロサービス 」ではなく（きちんと複数形で）「Microservices」と発信されていたのが印象的だった。というのも、「マイクロサービス」といった時に、「小さく分割された業務機能を実現する1つのサービス、あるいはバイナリ・モジュール」のような謎の誤解をしている（と見受けられる）ケースを見かけたことがあった。なので、そういった誤解を生まないように、「小さく分割された業務機能を実現するための複数のサービス」であることを意識づけようと、きちんと複数形で呼ばれていたのがよかった。
　
Amazon.comの話は、倉庫を軸に、入庫のinboundチームと、出庫のoutboundチームがいるところからスタート。共有DBで……みたいな辛そうな話から始まり、片方のチームのDBスキーマ変更がもう片方をバグらせたりとか、リリースタイミングがビジネスのスピードに追いつかないとか、あるあるな話が盛りだくさん。Amazon.comですらそうなんだな、と思うと逆に安心できる気もしてしまってよくない（笑）
　 Amazom.comもALBの発表以降、MSAチックになりつつあった、と。この話に関連して、データ・ドリブンにマイクロサービス化していくと、結局注文や品物といったデータの部分が巨大なモノリスになるのでよくない、という話が。覚えておこう（いつかハマる気がするが……）。
　
AWSを利用した事例、ということで、Mapbox社、インティメート・マージャー社、Nike社の事例が挙げられていた。とりあえず資料を見つけたので、後で読むべくメモしておく。

aws.amazon.com www.youtube.com medium.com 　
開発者に向けて、ということでGraphQL（AppSync）の話とか、Web+DB Pressの記事に言及する場面もちらり。確かにGraphQLはある意味BFFといえばそうなのかもしれない、と思ったり。
最後の方で、Envoyの開発者の言として紹介されていたのが、アーリーステージのスタートアップの場合は無理にマイクロサービスにせず、顕著な問題が出るまではモノリシックで良い、という話が。確かにマイクロサービスは複雑だから、それによってリリースのタイミングを逃すなんてことになったら、それはそれで収入に繋がらないので、ビジネス上の判断で捨てるべき時もあるんだな、と学んだ（活かせるとは言ってない）。
　
　

[まとめ]

・認証認可を考える時はデータ主体も意識する
・SLOは闇 ・BFFはコミュニケーションが大事
・WebComponents一度実戦投入してみたい
・マイクロサービス関連の公開資料たくさんあるので追いかける
・AWSDevDayに参加した2日間通して、色々と試してみたいことが積み上がった
・AWSの新オフィス初めて行ったけどとても綺麗で良かった