Developers.IO 2019に行ってきました
こんにちは、tkyです。
本日はClassmethodさんのDevelopers.IO 2019に参加してきたレポートブログとなります。 とは言え本家ブログ側に各レポートブログがあるのでこちらではサマリと感想などを綴ることにします。
Developers.IOについてはこちら dev.classmethod.jp
各セッションのレポートはこちら dev.classmethod.jp
ハッシュタグは #cmdevio のようでした。
twitter.com
ブルボン総選挙もやってました。
濃密なスケジュールの中見てきたセッションはこちらになります。
| 時間 | Room | タイトル | 発表者 |
|---|---|---|---|
| 10:30~11:15 | Room2 | 認証の標準的な方法は分かった。では認可はどう管理するんだい？ | 都元ダイスケ 氏 |
| 10:30~11:15 | Room H | claspではじめるサーバーレス開発 Google Apps Scriptで簡単自動化 | 武田隆志 氏 |
| 12:24~13:30 | 昼食休憩してました | ||
| 13:45~14:30 | Room3 | サーバーレスの基本とCI/CD構築 & 運用 〜システムは動いてからが本番だ〜 | 藤井元貴 氏 |
| 14:45~15:30 | Room3 | エンジニアも知っておくと得する、デザイン組織とデザイナーマネジメント | ベイジ 枌谷力 氏 |
| 15:45~15:30 | Room3 | サービスを爆速で立ち上げるためのSaaSの活用 | 諏訪悠紀 氏 |
| 16:45~15:30 | Room5 | 障害に備えたアーキテクチャを考える「あのとき何が起こった！？」 | 坂巻一義 氏 / 吉井亮 氏 |
| 17:45~15:30 | Room5 | Amazon ECSを活用したAWS運用自動化サービスの裏側を包み隠さず解説 | 伊藤祥 氏 |
| 18:45~ | Room11 | 懇親会 |
認証の標準的な方法は分かった。では認可はどう管理するんだい？
公式レポート
感想
通常APIを設計するときにほぼ必ず考慮するであろうアクセス制御、 例えば「一般ユーザ」「管理者ユーザ」で取得できるデータの内容が異なったり、 更新できるデータの範囲が異なったりしますが、実際そのような要件に対して設計アプローチしていくのか、という話となります。
ISO 10181-3で Access Control Framework という名称で標準化されている模様で、この考え方に基づきながら解説されていて非常にすんなりと理解できた気がします。
理解しやすくするために以下のワードが出てきました。
- 操作する人・・・ユーザ
- 操作されるもの・・・・リソース
- 何かの操作・・・アクション
そして上記の『「一般ユーザ」「管理者ユーザ」で取得できるデータの内容が異なったり』これがまさにアンチパターンとなりうる状況だったようです。 前提としてユースケースが異なるのでそもそも同じアクションで管理しては ~ダメ~ (複雑になるので推奨しない)そうです。 別々のAPIで設計することで、余計な条件分岐もなくなりテストしやすくなりそうです。 確かに、不具合が発生したときにその状況を再現しづらくなったり、原因特定に時間がかかるう要因になりかねないですし、なるほどと思いました。私の中ではここが一番収穫でした。
P34に書いてありますが、重要です。 - ユースケースとアクションをちゃんと定義して - 誰が何にアクセスできるのかきっちり決める
アクションがわかったところで、何を以てそのAPIを叩いてOK/NGなのか、 ですが、いろいろあるんですよね。
- ユーザが持つ権限(どのAPIと叩いて良いのか)
- オーナー権限
- 役職、リーダー
アクセス権は ユーザ 自身に紐づくものと その役職(Role) に紐づくものがあって、これまでの話はユーザ側のものでした。
ここでユーザには関係ない役職という軸も出てきます。もうそろそろ脳のキャパシティを超えてきました。
で、このあたりをじっくり観察するとAWSのIAMによるアクセス制御がまさにこのことだそうで、きれいに締めくくられ 後味の良いスッキリとした気持ちでセッションが終了しました。
claspではじめるサーバーレス開発 Google Apps Scriptで簡単自動化
公式レポート
感想
自社でGASおじさんと化しているtkyですが、clasp自体知らなかったため、知識を得るために聴講。 GASができることと、デメリットを解消するためのclaspについて、 クラスメソッド内のGASの活用事例などが聴けました。 ※claspについては既知の人だと「聞いたことある内容だ」という感じの初級者向けセッションとなりそうです。
GAS、Google Chrome上で開発できす素早さとスプレッドシートとの連携が強力で便利なのですが、 - JS 1.6である - コードの差分管理ができない - コードフォーマッタなど活用できない
と言ったデメリットが挙げられる中でclaspというCLIツール(Nodeモジュール)の存在を知って心のなかで大きく盛り上がりました。 TSでかけるのが大きいかもしれませんね。ローカル開発となるのでgitも使えるので楽だと思いました。
メリットしか無いのでは？とも思いますが、セッションでもありました通り - 手軽さが減る - 非開発者には敷居が上がる
などもありますし、エクセルの標準関数でできることも多いので、目的に合わせてGASやclaspを利用していくのが良いなと改めて感じました。
活用事例としては以下のようなケースでGASで定常業務にかかる負担を減らしているようです。なるほど！！ 1. スプレッドシートをJSONにしてS3にアップロード 2. GAとMackerel連携。リアルタイムユーザを定期的に送信して可視化する 3. Backlogチケットをスプレッドシート連携（定例時に転機するのに活用） 4. Gsuiteのグループ作成（メーリングリスト）Admin SDK Directory APIを叩いてグループ一括作成 5. Gsuiteのグループ棚卸し、グループ情報をスプレッドシートに出力
クラスメソッド内でのGASの活用事例もしれてとても良いセッションでした。
サーバーレスの基本とCI/CD構築 & 運用 〜システムは動いてからが本番だ〜
公式レポート
感想
入場ギリギリになってしまい立ち見となりました・・・ CI/CDで考慮すべき項目やAWS構成について理解できるセッションとなっていました。
CI/CDにおいて重要なのはセッションにもありましたが以下ですね。 - いつでも動く安心感を手に入れる - デグレに気づける - テストコードでは見つけられない不具合の回避 - オペレーションミスによるデプロイミスの回避
人的ミスをそもそもなくす、仮に発生しても水際回避したり、早期発見できるようになるのがCI/CDの強みだと思います。
テストコードでは見つけられない不具合 についてはピンと来なかったのですが、
AWSサービスを使うにあたり以下のような事象がそれに該当するようですね。なるほど。
- CloudFunctionのスペルミス
- IAMの権限不備
- DBの権限不足
デプロイ時に気をつけるべきポイントとしてのIAMアクセスキーの流出についても興味深かったです。 実際にやってみないとこういった知見にたどり着けないと思うのですごいなぁと思います。（AssumeRoleという機能を考えているAWSもすごい・・・）
最後に監視の話、何を、どのくらい検知したら、いつ、誰にどんな内容を通知するのか、 これをきっちり考えないと、精神的に摩耗してしまいますし、オオカミ少年になってしまいますね。
サービスもリリースして終わりではなく、リリースしてもやることは多くいかに素早く改善していくか、 やはりリリースしてからがやはり本番だ、というタイトル通りのセッションだったと思います。
エンジニアも知っておくと得する、デザイン組織とデザイナーマネジメント
クラスメソッドさんと一緒にお仕事をしている会社さんのセッションでした。 baigie.me
公式レポート
レポートブログはないので資料のみです。
https://baigie.me/download/pdf/devio_191101.pdf
感想
本セッションではデザイナーという職種の細かいジャンルとデザイナーのタイプの紹介がメインとなります。
セッション時、「デザイナー職の人と一緒に仕事をしている/したことがあるか」という質問が上がり 結構な数の手が上がっていました。やはりデザイナーと関わっているエンジニアが日々増えているのだろうと、感じています。 そんな中、エンジニア＋デザイナーを含む組織をマネジメントする必要も出てくるのは、そのとおりですね・・・
デザイナータイプについてはエンジニアにも通ずるというか全ジャンルに通ずるところがあると思いました。 そしてお互いが相容れない存在で「混ぜるな危険」の意味も理解できましたｗ
- 挑戦的⇔保守的
- 感覚的⇔論理的
上記の軸からみる分布 - 理想実現型(先駆者) - 成果追求型（データドリブン) - 共同作業型(調和) - 実務遂行型(ドキュメント命)
MBTI診断を大きく4分割すると上記のタイプに分かれそうだな、という印象を受けました。
皆さんはどんなタイプでしたか？
サービスを爆速で立ち上げるためのSaaSの活用
公式レポート
感想
Auth0、stripe、 CircleCI を使ってサービスを立ち上げた話となります。
それぞれ、認証、決済、CI/CDを司り、これらを使って約2ヶ月でDevelopers.IO Dafeができたとのことで驚きのスピード感（と技術力！！）
stripeについてはテスト用のクレカを利用できたり、いざという時の返金も行えるようになっているということで、まじで便利じゃん(語彙力)と思いました。
本セッションでも伝えていたことですが『プロダクトにとって最も大切なもの(コア機能)はなにか』が重要だという印象を受けました。 実際認証の仕組みやDBなど自前で用意しようとすると車輪の再発明にもなりますし、運用コストがかかってきます。 本来のサービス、プロダクトのあり方を考えて適材適所でSaaSを利用していく判断も必要になってきますね。
最後に、エンジニアさんは実際にDevelopers.IO Cafe内で開発しているらしく、超羨ましい・・・と思った次第です。
障害に備えたアーキテクチャを考える「あのとき何が起こった！？」
公式レポート
感想
2019年8月23日 東京リージョン障害を通じて、どのような対策を取ると良いのか、 実際に稼働率を極限まで高めようとした際の構成及びコスト試算などを共有するセッションで、とても興味深かったです。
障害発生時の実際の調査内容についてもセッション内で共有がありました、こちらも合わせて見るとより流れが把握できそうです。
障害発生時、どのようなシステム構成を取ると良いのかについては Well-Archicted Framework 信頼性 が参考になるそうです。
システム設計運用の大局的な考え方や、設計原則のベストプラクティス、システムの最適化度合いを評価する視点をもてるようになるための資料で、
ちょうど11/1当日？くらいに日本語翻訳版が出たようです。
ドキュメントがいたれりつくせりですごいっすね、AWS・・・
正直このあたりから自分の知識量を超えていて理解が追いつきませんでした。
で、その上で稼働率を極限まで高めるために、99.0%、99.9%、99.99%のようにしていくとどういった構成になるのかをまとめていました。 ここからわかることは、落ちないような構成を取るためには相応のコストが掛かるということ、 また構成だけでは限界があるので、落ちたあとにいかに早く復旧できるかが稼働率を高めるポイントにもなるというところが印象深かったです。
Amazon ECSを活用したAWS運用自動化サービスの裏側を包み隠さず解説
公式レポート
感想
AWS運用自動化サービス「opswitch」のシステム構成や開発環境などの紹介セッションとなります。 こんなところまで見せてしまって良いんですか、、、というくらい濃い内容でした。 運用の自動化に対する課題の解説と、運用を自動化するサービスの説明に分かれています。
昼一のセッションにもありましたが、リリースして終了ではなく、リリースしてからが本番であり、運用は決して逃れることのできない必要作業になりますが、 やはり自動化して極力ヒューマンエラーを避けていきたいところ。
そこでopswitchという運用自動化サービスが登場します。 EC2/RDSインスタンスの起動・停止、バックアップなどのタスクを組み合わせてジョブ実行できる機能などが魅力的です。
内部のアーキテクチャについては、大きく３システムで構成されていて各システムで扱っている技術が異なっているところが面白いなと思います。 また、コア部分のシステムについてはそれぞれ必要なリソース(CPU,メモリ)や役割などが異なるため関心事別にクラスターを分けて構成しているとのことで勉強になります。
かなりディープな話だけあって知識的に置いてけぼりをくらいながらも知らない領域を知る機会を得られてとても良かったです。
懇親会
最後は再演セッションがいくつかあるなか、並行で懇親会がスタートしました。 食事が美味しい・・・ 登壇されていた方をうまく見つけることができずでしたが、数名の方とコミュニケーションを取ることができました。
おわりに
最近AWS等インフラの構築/設計に関わる機会が増えており、自分の知らなかった情報を手に入れることのできた 貴重な体験でした。
