こんにちは。
藤井 (@yoshiyoshifujii) です。
今回、弊社のかとじゅんさんが登壇されるということと、興味深いいくつかのセッションを聴講するという名目で参加させていただきましたので、レポートを上げさせていただきますー。
私が聴講させていただいたセッションは、以下となっており、それぞれ簡単に内容と所感を述べさせていただければと思います。
- (10:00) セキュア開発プロセスをアジャイル開発に適用するには - 徳丸 浩 氏
- (11:00) ドメインモデリングの始め方 - 加藤 潤一 氏
- (15:00) 外部に依存したコードもテストで駆動する - 和田 卓人 氏
- (16:20) クックパッドの動画事業での AppSync 活用事例 - Firebaseからの移行 - - 渡辺 慎也 氏
(10:00) セキュア開発プロセスをアジャイル開発に適用するには
https://aws.amazon.com/jp/aws-devday-tokyo-2018/sessions/#sd01
徳丸さんのお話を聴講しました。
内容
内容としては、「アジャイル開発とセキュアプログラミングは相性が悪い。」という件について、WaterFallモデルでの開発におけるセキュアプログラミングに必要な要素を整理したうえで、アジャイル開発のイテレーティブなプロセスで取り組むタイミングとインクリメンタルに取り組むと良いよって部分を具体的にお話されていました。
結構いろいろなエッセンスを40分の中でぎゅっとお話されていたので、全部、追い切れてはいないのですが、メモれているあたりからピックアップして書きます。
- セキュリティ教育は、イテレーションの外で済ませておく。イテレーションの中ではしない。
- 脅威分析はインクリメンタルに実施する
- 脆弱性対策をあとから実施するということはできない。最初から対策が必要。
- フレームワークに頼るのを推奨する
- フレームワーク選定にはぜひセキュリティを考慮に入れて欲しい
- 脆弱性診断をインクリメンタルに実施するのはコストや納期の面から現実的ではない
- 外注に出すにも需要が多くなかなか即応できない
- 脆弱性診断をインクリメンタルにするには、新に追加した部分のみ対象として、自動診断ツール等を用いて差分に対して実施すると良い
- OpenVAS を毎日0時に実行するとか、自動化させてインクリメンタルな脆弱性診断も可能
- OWASP ZAP は無償でそこそこ使えるとのこと
- JavaやPythonのAPIもあるし、CLIもあるので、CI環境に組み込むことも可能
- 脆弱性診断をコミットの前、コミットの後(夜間バッチ)、ステージング環境のデプロイ直後などのタイミングについては、宗教論争のようにベストを断定するのではなく、自社で検討して決めるべき
所感
盛り沢山でした。そして、徳丸さんのデモはすごい。分かりやすい。基本的にアジャイルだからウォーターフォールだからといって、セキュアプログラミングの要素を欠けさせていいわけではなく、どのフェーズで取り組むべきか、インクリメンタルに実施する必要があるので、自動化を取り入れる必要あるよねというお話で、実践していくうえで、いかに仕組み化したうえで、対策を継続できるかが鍵だなーと思いました。
分かっているけど、なかなか実践できていない現場もあるんだろうなーと思いました。
(11:00) ドメインモデリングの始め方
https://aws.amazon.com/jp/aws-devday-tokyo-2018/sessions/#sd02
我らがかとじゅんのお話。
内容
DDDに取り組むぞってなったうえで、いざドメインモデルを考えようと取り組んだときに、どこから手をつけたら良いのか、そのドメインモデリングの前段階で必要となってくる取り組みとして、 RDRA (ラドラ)や、 ICONIX とDDDのエッセンスを使って、モデルを抽出してコードに落としていくあたりについてのお話でした。
資料はこちらです。
所感
こちらもかなり盛り沢山でした。RDRAとICONIXとDDDを40分できれーにまとめておられて、すごいと思いました。また、新しいワードとして、 EventStorming というのが出てきました。
セッションの中で解説しておられましたが、DomainEventを見つけて、Commandを見つけて、Actorを見つけて、集約を見出すといったボトムアップな分析手法として、最近、注目しておられるとのことで、私もかなり興味があります。 ぜひ、ワークショップなりを、体験してみたいと思いました。
(15:00) 外部に依存したコードもテストで駆動する
https://aws.amazon.com/jp/aws-devday-tokyo-2018/sessions/#sd05
t_wadaさん！TDDで有名なt_wadaさんのお話を今まで機会なく一度も聞いたことがなかったので、とても楽しみにしておりました。
内容
アレクサスキルを実装しているAWS LambdaのJavaScriptコードをテストするとのことで、TDDのエッセンスをふんだんに使った内容でした。
- テスタビリティの無いコードならば、こじ開ける必要がある
- テストの無いコードをレガシーコードと呼ぶ
- 「あなたが書いているそのコードにテストがないなら、あなたは延々とレガシーコードを生み出し続けているんですよ！」は名言ですよね
- レガシーコードを受け取ったら、とにかくHappy Pathでいいからテストで動かす
- Mockの選定
- alexa-skill-test-framework
- 高機能かつ抽象化されており細かいところに手を入れにくい。
- Easy指向。
- aws-lambda-mock-context
- 機能が少なく、レイヤが薄い。
- Simple指向。
- ここは後者でいこう。
- まずは、ザルなテストを作って、次に完全一致のテストを書くと動かない
- ランダム性により通らないのが分かるので、まずランダム性を排除
- コードを変更するには、テストを整備する必要があるが、テストを整備するにはコードを変更しないといけないデッドロック。
- ので、慎重に穴を開けていく必要がある。
- 「情報」と「データ」の違い。
- 「情報」は意味のある(目的を持った)もの。
- 「データ」は事実の値の集り。
所感
普段、言語化できないけど、自分が心がけていることを、理論として改めて学び直せました。アレクサスキルのよーに、サンプルコードが依存ゴリゴリでまだまだ普及もしてない中で、テスタビリティを見出していくと、自ずとコードが整理されていく様は、とても学びがありました。 とにかくテスト、話はそれからだ！の信念を持ってやっていきたいと思いました。
(16:20) クックパッドの動画事業での AppSync 活用事例 - Firebaseからの移行 -
https://aws.amazon.com/jp/aws-devday-tokyo-2018/sessions/#sm06
クックパッドさんが、FirebaseからAppSyncに乗り換えるにあたり、既存のMicroservicesの基盤と連携しつつ、新な価値基盤のMicroservicesをフロントのCommandを受けるところから、QueryをAppSyncのGraphQLでリードできるようなあたりで、Goを中心にgRPCを活用して環境を構築していったお話でした。
内容
とても盛り沢山で語られる言葉の端々から先端技術を追求してチャレンジして工夫を凝らして実現していった感がありとても興味深い内容でした。
資料は以下です。
以下はメモ。
- AppSyncは、GraphQL + MQTT over Websockets
- Live配信では、一気に認証がかかるのでCognitoに負荷がかかるという気付き(制限緩和で乗り切る)
- AppSyncからアプリへのファンアウトは、細かくするよりある程度バッファリングするほうが良い
- Microservices化が進むと、各Serviceの実装負荷があがってくるため、Service Meshが必要
- Sidecar ProxyのEnvoy経由で通信するようにした
- AppSync ResolverでDynamoDBを使っていたが、DynamoDBのWriteキャパシティがボトルネックになった
- もろもろ検討したが、Data Source type Noneにした
- 永続化は別で実施しているため、AppSyncの永続化データは不要と判断できた
所感
AppSyncを使うために、Read Modelの生成のあたりでGoやgoroutin、gRPCをごりごり使って、ごりごり開発して実現している印象を受けました。とてもやりがいあって、現場のスキルも問われて、たのしそうだなーとシンプルに思いました。 これは負けてられないなーと思いますし、ぜひ我々もトライしたい領域だし先んじていきたいと思える内容でした。 なんか、テンションあがって、無駄にトライしたい欲求が出てきました。
まとめ
今回、AWS Dev Day Tokyo 2018のセッションをいくつか聞くことができて、改めて学びも多くあり、刺激も受けて、さらなる飛躍に向けて、キャッチアップとトライを邁進したいと思いました。
私個人でなく、組織として、チームとして、色々と飛躍に向けたトライをしていけたらと、そういった行動や貢献ができるように取り組みたいと思います。
以上です。
