[レポート] Developers.IO 2019 Tokyo に行ってきました
2019-11-05やってみた系ブログ Developers.IO でおなじみのクラスメソッド株式会社が主催するカンファレンスイベント Developers.IO 2019 Tokyo に行ってきたので、聴講したセッションの中で特に印象に残っているもの、参考になったもののレポートという名の感想を書いておきます。
ちなみに昨年も参加したのですが、今年は昨年以上のセッション数で、事前エントリー、当日の来場者もかなり多かったようです。
https://t.co/8XSAiURBp3 2019東京にご参加頂きましてありがとうございました。1200名エントリー、晴天に恵まれて約900名ご来場、スタッフ約100名の大きなイベントとなりました。スポンサーの皆様、登壇者の皆さんもお疲れ様でした。
— さとし🍅 (@sato_shi) November 1, 2019
イベント当日はハッシュタグ #cmdevio でたくさんの方がツイートしているので、当日の雰囲気を味わいたい方はチェックしてみてください。
目次
セッションごとの感想
聴講したセッションごとの感想を簡単に書いていきます。
なお、 Developers.IO のセッションの特徴としては、セッション後 (もしくはセッション前) に資料が公開されます。また、登壇者によっては資料だけでなくセッション中に話した内容や補足情報をまとめたブログをアップされている方もいるので、当日現地に行けなかった人たちにも優しいイベントになっています。
ちなみに会場は日本橋のベルサール東京日本橋でした。
Developers.IO CAFEのこれまでとこれから 〜顧客体験へのフォーカスから考える技術選択〜
クラスメソッドの社長 横田聡さんによるセッションでした。
内容としては、クラスメソッドが運営している完全キャッシュレスカフェ Developers.IO CAFE の開発に関する内容でした。開発に関する内容といっても具体的な技術の話というよりは、サービス開発において大事なことをたくさん知れたセッションでした。
特に印象的だったのが、 体験をハックする という内容です。
Developers.IO CAFE は Amazon Go を参考にしているのですが、 Amazon Go 自体はなんの仕組みも技術も公開されておらず、わかっているのは「入店して商品を取って退店すると決済が完了している」という 体験 のみ。その体験が要件定義となり仕様書となり…で、実現できるための技術、開発は有志の社員の方々に丸投げだったようです。
体験を形にするというのは非常に難しい気はしますが、ユーザのことを一番に考えると、本当に必要な機能やサービスはユーザの体験からわかるものなのかなーという納得感がありました。
また、 開発者や社内の人などの関係者だけでなく、実際のユーザ・カスタマーのフィードバックが大切だ という話もありました。
Developers.IO CAFE ではカスタマーフィードバックをたくさんもらうために、開発-リリースのサイクルを何回も回すことを意識していて、結局 1 年間で 4 周もサイクルを回されたようです。さらに最近では企業や大学とコラボして期間限定の店舗をオープンするなどして、いろんな方面からカスタマーフィードバックを得ているということでした。
さらには CAFE で働く人たちからもフィードバックをしてもらって、より心地よいユーザ体験を追究していくとのことでした。
ちょっと長くなりましたが、まとめると、サービス開発においては技術の選定や上司への提案からスタートするのではなく、まずは体験からスタートするのが良い というのが印象的でした。
また、横田さんは良い意味で社長感が無くて、とりあえずやってみる精神が非常に強い人だなという印象でした。
AWSのすべてをコードで管理する方法〜その理想と現実〜
Infrastructure as Code に関するセッションでした。
内容としては、 CloudFormation 大好きな
濱田孝治（ハマコー）@hamako9999
さんが主観たっぷりで CloudFormation について語る内容でしたが、 CloudFormation を既に使っている人にも、これから使おうとしている人にも刺さるような内容でした。
ちなみに自分は AWS CDK の GA に合わせて重い腰をあげて IaC デビューした身なのでほぼ後者にあたる人間だったのですが、参考になる部分がたくさんありました。
まず最初は、そもそも Infrastructure as Code とはなにか？ というセクションだったのですが、ここで出てきた「AWS CLI との違い」による例がわかりやすかったです。
AWS CLI は 処理を定義する ので、実行した回数だけリソースが増えていきます。一方で IaC は 状態を定義する ので、 (テンプレートを変更していなければ) 何度実行してもリソースは変化せず、数も増減しません。
この比較は、あー、なるほどと思いました。
もうひとつは、 CloudFormation レンプレート作成時にどのような観点でスタックを分割するか という内容が参考になりました。
CloudFormation ではなく AWS CDK での経験なのですが、複数のリソースを扱おうとすると、テンプレートはかなりのボリュームになります。例えば前にやった例では、 CloudWatch Events と Lambda で EC2 の自動起動・停止を実現する環境を CDK で作ったんですが、そのときに生成された CloudFormation テンプレートが 170 行にもなりました。テンプレートファイルに免疫がない自分にはこの行数でも ウッ となったんですが、もっと複雑なリソースの組み合わせになると 1000 行を超えることもあるようです。
そうなってくると１つのテンプレートファイルで扱うのは非常に辛いため、いくつかのテンプレート・スタックに分割して管理するのが良いようです。
具体的には、リソースの依存関係や変更が発生する頻度などが分割の条件 (というか考え方) になるようです。
例えば、 VPC、Subnet、IGW、RouteTable、EIP などは変更がほぼないため、１つのテンプレートにまとめてしまってよくて、変更が頻繁に発生するであろう SecurityGroup はそれだけで１つのテンプレートにしてしまう、といった具合です。
特にテンプレート・スタック分割はなるほど感が強く、内容としては CloudFormation での話でしたが、 CDK でのスタック分割にも適用できる考え方かなと思いました。
CDK は TypeScript でまさにコードっぽくテンプレート (になるもの) を書くことができるので非常に便利ですが、やはり大元となる CloudFormation についても勉強が必要だなと思いました。
サービスを爆速で立ち上げるためのSaaSの活用
タイトルの通り、 SaaS (Software as a Service) を使って爆速でサービス、特に SaaS を立ち上げようという話でした。そうです、 SaaS を活用して SaaS を作ろうという話です。
利用者としてみる SaaS と、提供者としてみる SaaS の両方の良いところがわかりやすくまとめられていました。
特に提供者としての SaaS は、パッケージ製品のようにユーザに個別で対応する必要がなく、今流行りのサブスクリプションモデルにもしやすい、ビジネスとしては美味しいところがたくさんあるというのが印象的でした。そんな SaaS は主に 認証、 課金・決済、CI/CD の 3 つの要素で構成されていますが、それらをスクラッチで開発するのではなく SaaS を活用しましょうという感じです。
具体的には、認証まわりは Auth0、 課金・決済まわりは Stripe、 CI/CD は CircleCI がそれぞれ紹介されていました。この日の他のセッションでは、これらを 三種の神器 としてより具体的に紹介されているセッションもあったようです。
SaaS は活用するもの という認識でしたが、それらを使って SaaS を作るという内容が面白かったです。また、 SaaS はビジネス的にもうまみがあるということから、今後は SaaS の開発をしているようなところが伸びていくのかなーと思いました。
障害に備えたアーキテクチャを考える「あのとき何が起こった！？」
「あのとき」とはもう皆さんご存知の 8月 23日 の AWS 東京リージョンの障害発生時ですね。
このセッションでは、あのときにクラスメソッドのブログ Developers.IO で何が起こったのか、どのような対応をしたのか、また、障害に対してどのような構成・準備が考えられるかについて話されていました。
Developers.IO への障害の対応としては、 Slack への通知、 ALB や WAF のログなどから情報を得て的確な判断と行動をするという、お手本のような内容でした。
ただこれができたのは事前にしっかりと準備をされていたからなので、 Slackへの通知 や 何が起きているか判断できるメトリクスの取得 、 想定障害と復旧手順の準備 が大事だということでした。事前の準備でもう一つあったのが ログを S3/CWLogs に出力する という項目です。障害時には該当のサーバなどに入ることすらできない可能性があるので、外出ししておきましょうという話です。これ自体はわかってたのですが、その先の ログの検索手順の確立 というところまでやっておく必要があるというのがグサッときました。たしかに S3 や CWLogs に外出ししておくのはいいのですが、それらに対する検索って結構やりづらいですし、 Athena を使うにしても検索用のテーブルを作ったりする必要があって結構面倒です。なので、ログは外出しでとどまらずにその後の検索方法までしっかり確認して準備敷いておかないとけないと感じました。
あと印象的だったのが、稼働率とコストの関係についての話です。
あのときの障害によって各所では「マルチAZでは足りない、3つにしよう」とか「東京がダメな時のためにマルチリージョンにしよう」という話が結構出ていたと思います。しかし、それらの対策をするにはコストも大きくなります。セッションでは、稼働率 99% の時のコストを 1 として、99.9%、 99.99%、 Mulch Region のそれぞれを実現するために必要なコストとアーキテクチャについて説明されていました。ざっくりとですが、 99% が 1 に対して、 99.9% は 25.65、 99.99% は 36.81、 Multi Region は 47.72 という比率でのコスト増となるようです。3AZ 化やマルチリージョンという発想を出すのは簡単ですが、大きくなるコスト、複雑になる運用との優先度を冷静に考える必要があるなと思いました。
サーバーレスの基本とCI/CD構築 & 運用 〜システムは動いてからが本番だ〜
サーバレスの基本はさらっとで、サーバレス開発における運用の方法 (テスト環境の準備、テストコードの書き方、セキュアなデプロイ方法 etc…) について、実際に担当されているプロジェクトを例に話されていました。で、この内容が非常に詳細にまとめられていて、サーバレス開発するにあたってはこのセッションの資料はかなり参考になるのではないかと感じました。
Git のブランチの運用方法から始まり、 CircleCI のワークフローの例、AWS リソースに絡むテストコードの書き方、デプロイ時に使用する IAM ロールとアタッチするポリシーの分け方、さらには運用が始まってからの監視についての内容まで、本当に盛りだくさんの内容でした。
実際のプロジェクトを例にした内容だったので、これからサーバレス開発を始めようと思っている人にも、すでに何かしらの運用フローで開発をしている人にも参考になるような内容でした。
このセッションはビアバッシュ形式での再演も実施されたセッションだったのでその当時は内容がはっきり入ってきていなかった部分もあったんですが、あらためて資料を見てみるとそのまとまり具合にただただびっくりしています。熟読したいと思います。
全体の感想
Developers.IO 2019 Tokyo に行ってきた話でした。
本当に各セッションに対する感想だけを書いたのですが、どのセッションも内容が濃くて参考になるものばかりで、 45 分のセッション時間があっという間に過ぎていました。
あとこれは去年も感じたのですが、クラスメソッドの人たちは本当に技術力と登壇力が高いなーと感じました。資料も見やすくてセッションの運びもうまくて、ただただすごいなと思いました。
また、後に資料がすべて公開されるというのも良いですね。当日は会場設備の関係で一部のセッションではスクリーンの調子がよくなかったりというアクシデントはありましたが、資料は後で公開されると事前に告知されていたので、安心感がありました。
あとは、ランチセッションで配られたお弁当が胃に優しいお弁当で、とても美味しかったです。
さらに会場ではクラスメソッド、ゲスト企業のブース、コワーキングスペースなどもあり、空き時間も楽しめるようになっていました。
今回技術的なインプットをたくさんすることができたので、得た内容、関連するに内容に対して実際に手を動かして自分の技術レベルを上げていきたいと思います。
comments powered by Disqus