Developers.IO 2019 Tokyoに行ってきた

other

　Developers.IO 2019 Tokyoに行ってきたので、聞いてきた内容についてまとめてみます。

「三種の神器」ではじめるSaaS生活

　主にビジネスサイド向けのセッション。パッケージビジネスからSaaSビジネスやサブスクリプションモデルへの転換をどのように行うのか、また、新規でSaaSビジネスを立ち上げるにあたって気をつけることは何か？を主軸として、具体的な例を交えながら事業の進め方を説明。

  • チャーンは2%以下にせよ
  • 利用開始の敷居を下げる
  • カスタマーサクセスに寄り添う
  • クーポン、プライシング変更は積極的にやる

　「チャーンがなく、新規ユーザーの流入が続けば、売上は右肩上がりになる。反面、パッケージビジネスからの転換は、キャッシュフローが大きく変わるので気をつけましょう」

三種の神器とは

  • Auth0 （認証、認可）
  • CircleCI (CI）
  • Stripe　（決済）

　「認証、認可、決済などは、多くのシステムで同じようなものが使われている。独自実装で車輪の再発明を行うよりも、既存のサービスを使ったほうがコスパがよい」

　「それ以外にも例えば、ソーシャルログインを実装しているシステムは多いが、連携先のシステムに仕様変更が加わったときは、すぐに追従しなければならない。Auth0などを利用していれば、追従やバージョンアップはAuth0側でやってくれる」（コストを転嫁できる）

　「パッケージビジネスと違い、SaaSは一日でも早くサービスを提供し、一日でも早くユーザーが定着すれば継続的な売上に直結する。余計なコストを掛けずに、本質的なサービスの開発に注力すべき」

感想

　ビジネス視点の話が主ではありましたが、開発を回す上でも、リソースを割くべきところに割く、という、半ば当たり前ではあるものの、あらゆる視点から考えると、実のところあまり意識できていないことを再認識できる場となりました。パッケージビジネスからの転換や、新たなビジネスを探る際には、スライドをひと目見てみることをオススメします。

AWS初心者が陥りやすい運用アンチパターンから学ぶ成功の法則

　AWSというよりは、運用に寄った内容。

　「止まらない！疲れない！危なくない！」というテーマをもとにアンチパターンの紹介とsolveするための具体的手法を紹介。

アンチパターン①、監視ができていない

　「正しい監視をすべき。正しい監視とは、外形監視（APIを叩いてレスポンスが正しく帰ってくること）や、アプリケーションログ、リソース監視を行うこと」

　要するに、「サービスが正しく動いているよね」ということを監視する。

アンチパターン②、監視しすぎ

　「メール来ても、あ、これね、無視しよ。みたいな状態になっているのはアンチパターン」

　対応しなければならないアラートと、そうでないアラートを分け、ある一定の緊張感を持って取り組まなければアラートを飛ばす意味がなくなる。

アンチパターン③、稼働目標が高すぎる

　SLOが高すぎると、DRなどのコストを掛けなければならないし、やろうと思えば無限にできる。サービスが停止したときに受ける損害と、それに備えるコストを天秤に掛け、正しい稼働目標を設定する。

アンチパターン④、想定外を想定していない

　想定外事象（インシデント）が起きたときの対応フローが制定されていないと、インシデントが発生したときの対応に手間取ったり戸惑うことになるので、予め制定しておくべき

アンチパターン⑤、運用を意識していない構成

　運用を意識しないと、いざ運用したときにコストが掛かったりして困ることになるので、ある程度運用を見越した設計をしておくこと

感想

　監視設計をする上では当たり前のことなのですが、振り返れば出来ていないこともあったり、出来ていたことが出来なくなる、みたいになったりもするので、初心にかえって運用を見直すきっかけになりました。「あるある話」としても面白いセッションでした。

AWSのすべてをコードで管理する方法 〜その理想と現実〜

　「Infrastructure as Codeの可能性と危険性を知ってもらいたい」

　結構主観が入っています、とのこと

Infrastructure as Codeとは？

  • すごく簡単にいうと「テキストファイルでインフラが出来上がる」
  • コード上でリソースの状態を定義する。同じテンプレートを複数回実行しても、状態に変更がなければアクションは起こらない
    • AWS Cliだと、毎回すべての変更アクションが行われる。（＝処理を定義する）

CloudFormation

  • yamlで書いたほうがいい
    • human readableだから
  • Conditionsは取り扱い注意

【CloudFormation入門1】5分と6行で始めるAWS CloudFormationテンプレートによるインフラ構築

なぜInfrastructure as Code？

  • 管理が簡略化される
  • テンプレートを使い回して複数のリージョンに展開可能
  • 変更管理が簡単

CLIで実行する

  • create-stack, update-stackを使うべきではない。イケてない。
  • deployコマンドを使うべき

怖い話

　Infrastructure as Codeの危険性を実例交えて。

  • スタック名が同じ別のテンプレートを誤って定義すると、元のテンプレートのCodeCommitが消えてしまう
  • 扱い方を誤るとすごく危険

CloudFormationのベストプラクティス

  • テンプレートは分割しよう
    • すべて同じところに書くと1000行を超えるボリュームになってしまう
    • スタックを分けよう
    • たとえば、ec2のテンプレートを作るときは、それに依存するiam等の設定も一緒に書いてしまってもよいかも
    • リソース間で参照する方法は色々ある
    • クロススタック参照
      • 簡単
      • 参照先があるスタック削除、変更しようとするとエラーになる
    • ダイナミック参照
      • 予め値を登録しておく参照方法
    • シェルで頑張る

運用上の辛さ

　事故事例やハマりポイントなど

  • 作成が終わらない
    • リソースにアタッチされているセキュリティグループを削除しようとした
    • よくあること
    • キャンセルしましょう
    • ECS
    • なぜか終わらない。原因が不明
    • コンテナも起動できて使えるが、結局タイムアウトしてロールバック（削除）されるためつらい
    • サポートに問い合わせるしかない
    • 対処方法
    • CloudFormationの公式ドキュメントを必ず確認する
      • 新機能等はすぐに使えないこともある
  • Conditions
    • 条件分岐が書けるが、インフラを定義するにあたって可読性が下がる
    • テンプレート自体を分けたほうがよいかもしれない
  • CloudFormationで作ったリソースをWebコンソールなどから手動変更してしまう
    • よくあること
    • 対処方法
    • AWS Configに良い設定がある

CloudFormationを実行する場所について

  • 個人のクライアント
  • EC2インスタンス
  • repositoryからのパイプライン実行

　結局最終的にはパイプライン実行になる。

感想

　最後の方が駆け足で終わってしまったのが残念ですが、濃密な内容でした。CloudFormationに寄った話でしたが、具体的なイメージが付きやすくてよかったと思います。

　現在のインフラ構成を見直す上で、Infrastructure as codeの持つ重要性や、そのデメリット、危険性などを認識することができるセッションでした。

Amazon CultureとAWSの設計思想 ～マイクロサービスアーキテクチャとアジャイル開発～

　Amazon Cultureと、巨大なプロジェクトを進める上での設計見直しの要点を細かく解説。

AmazonのCultureについて

  • イノベーションを起こすことを大切にしている
  • ユーザーが求めるものは尽きることがない
  • 言語化、顕在化していないものもある
  • お客様を起点に考える

　「今後何が変わるかではなく、何が変わらないかを考えるほうが知見を得られる」

  • Working backwards
    • 顧客を起点に逆算する
    • 会議が独特で、「いるだけ」というのは基本的に許されない。必ず発言し、議論する。
    • 社内とはいえかなり攻撃的になるので辛くなる人もいるらしい
  • 策に対して結果を求められない文化
  • 長期に渡る誤解を厭わない
    • kindleは当初成功とは呼べなかったが、長期的なアプローチを続けることで
  • イノベーションのために失敗を受け入れる
    • 大きな失敗をしなければならない
    • 失敗を恐れず、学ぶきっかけにしなければならない
    • fire phoneは実例のひとつ
    • 発明をやり遂げるためには、失敗を迎合すべき
    • 失敗で得たものはalexaに生かされている
  • 人事評価
    • KPI達成は、論理的に起こり得ない
    • 達成できたのだとすれば、達成できるに過ぎない目標を設定したことを咎められる
    • 目標はチャレンジングである必要がある。
    • 目標達成は人事評価に結びつかない
    • 工夫のプロセスと結果、失敗へのアプローチが評価される
  • Narrative（文書）文化
    • PowerPoint（PPT）は禁止
    • 話者のスキルやリズムに依存する
    • 重要な決定を伴う会議ではPPTは禁止
    • wordで文書化する
    • 本人がいなくても文書は成果物として存続する
    • 属人化が起こり得ない

マイクロサービスアーキテクチャ

  • 目的を揃える
  • HTTPSのAPIでのみ連携
  • お互いはブラックボックス

  • デメリットも多い

    • アプリケーションリポジトリの数が爆発的に増える

　AmazonはMonolithic Architectureを採用していた。

  • 密結合
  • メンテナンス困難
  • スケールアウトが不可能

　Deploy, Releaseに対する負荷が高まるため、属人性が最大化し、組織に新しくJOINした人間が活躍できなくなる。仕組みで防ぐことは難しい。

　アプリケーションを細分化し、スピードに拘るための小規模チーム「Two-Pizza Teams」を作った。

  • チームはDeploy, Releaseの権限を持つことがMust
    • MSAを採用するにあたって非常に重要
    • これが無いと、Deploy Release権限を持つ人に属人化するので、問題が解決しない

　Cloud Nativeにする

  • リソースを伸縮可能にする
    • stateless
    • 冪等性
    • CI/CD

　Cloud Nativeだからアジャイル。だけど、ドキュメントをどのように運用するかについてよく聞かれる。アジャイルは「価値の最大化」のみを目的として手法の変更を行うべき。価値に繋がるかどうかが主軸。

　マイクロサービスとAPI

  • API連携は疎結合
    • APIへの改修、新規APIのリリースは最大限注意しなければならない
    • ドキュメントを書くのか
    • コード＝ドキュメントとするのか
  • 例えば、Hotfixレベルの事象であればドキュメントを書くよりもスピードが大事かもしれない

　マイクロサービスアーキテクチャは「マイナスのほうが遥かに大きくなる」

感想

　内容非常に濃く満足。特にCultureのところは為になる話が多く、組織拡大においての課題感が見えた気がしました。

データ分析基盤、どう作る？システム設計のポイント、教えます

　お客様と協業してプロジェクトを進めるにあたって、「スモールスタートで進めたい」という相談をよく受ける

  • 早く始めたい
  • 安く始めたい

　最小構成の例として、「Local PCからCSVでS3 bucketにアップロードし、RDSに取り込んでBIツールで分析する」

　ネットワーク周りを検討する

  • セキュリティ
    • public subnet or private subnet + 踏み台
    • 専用線引くことも考慮する？

　「夢を見すぎない。まずはテキストで表現できるデータから」

　「事前に整形できるデータは整形しておく。たとえばJSONならCSV、TSVなどにしておいてほしい」

分析しやすいデータ

　Tidyデータ（整然としたデータ）を準備する。1レコード1行の行列データが望ましい。

  • データレイクはS3がAWSのお作法
    • S3はIO性能すごく高い
    • AthenaやSpectrumなどで直接クエリを投げることもできる

　データレイクとは？

  • 生データが基本だが、一次加工したデータも含む
    • ただし、無秩序にどんどん溜めていけばいいというわけではない
    • それはデータレイク（湖）ではなく、データスワンプ（沼）
  • Lake Formationという簡単に環境を構築できるサービスがある

　データ加工

  • データクレンジング
  • Not Tidyデータ -> Tidyデータ
  • CSV -> Parquet

　検索しやすくしたり、集計しやすくする。

　データ分析

  • Lambdaは相性が悪い
    • 最大実行時間が15分なので、そもそも出来ないことがある
    • パラレル処理（あまり時間が掛からない処理）はSNS -> SQS -> Lambdaで抜けもれなく処理させる。

　S3バケット構造

  • フォルダで階層を分けるのが望ましい
    • データ検索が楽になる

　データウェアハウス

  • 高速にデータ検索・活用ができること
    • 本命はRedshift (Spectrum)
    • 次点はRDS系
  • データレイクを直接使うという手もある
    • updateが出来ない欠点はあるので、それならRDS？
  • データロードはバルクロード
    • insertなどは時間がかかり過ぎる

　ETL（Extract -> Transform -> Load）かELT(Extract -> Load -> Transform)か

  • 加工してからDWHへロードするか
    • 仕組みが複雑になる
    • DWHには負荷が掛からない
  • 先にDWHにロードしてから加工するか
    • 仕組みはシンプルになる
    • DWHに負担が掛かるので夜間にやるなど工夫をしないといけない

　データ提供方法

　CSVで吐いてExcelで加工したい、という人がよくいるが…、

  • 基本はBIツール
    • BIツールで経営判断できるようにしておくべき
    • CSVにエクスポートして…というのはもったいない
  • ユーザー管理はBIツール側に寄せるべき
    • データベースユーザーを社員に持たせるというのは違和感ある

　工夫が必要な要素

  • データを分析する仕組みがまだAWSには不足している
    • MinimumでやろうとすればExcelでもできるが・・・

　性能

  • やってみないとわからない
    • 予算は余裕を持って確保すべき
    • 必要なら足せばよい、余裕があったらラッキー

　セキュリティ

  • AWS側の監視サービスに寄せる

感想

　データ分析の需要が高まったとき、まず迷うのがデータレイクの設計ですが、このセッションで道筋が見えた気がします。特に、AWSを利用してデータレイク、データウェアハウスを作る場合、S3を使うのが半ばベストプラクティス化しているというのは目からウロコでした。

障害に備えたアーキテクチャを考える「あのとき何が起こった！？」

　2019/8/23に起こった大規模障害からの学び

  • 冷却装置のソフトウェアバグによりオーバーヒートが起こったことが原因

　こういう事態に備えて運用をしっかり整えることが大事。異常があればすぐに気づき、調査のための材料を素早く揃えること。

AWS Well-Architected Framework 信頼性の柱

　Well-Architected Toolを活用してリスク評価を行う

　信頼性に関する観点

  • 復旧手順のテスト
    • 本番環境で復旧手順がちゃんと動くかテストする
  • 障害から自動的に復旧する
    • 例として、閾値を超過したらEC2を再起動するなど
  • 水平方向スケール（スケールアウト）でシステムの可用性を向上させる
    • 単一障害点をなくす
  • スペックの推計をやめる
    • キャパシティプランニングよりも、オートスケールを活用する
  • 自動で変更を管理する
    インフラに対する変更は自動化する（CloudFormationなど）

　Well-Architected Framework内で聞かれることの質疑応答例が続くので内容は割愛。

AWS Personal Health Dashboardは便利そう

　バックアップ自動化

  • Amazon Data Lifecycle Manager
  • AWS Backup

　Well-Architected Frameworkのwhitepaperが日本語化されたらしい

障害にそなえるアーキテクチャの具体例

  • 週１回数時間程度のメンテナンスウィンドウを設ければ幸せになれる

　目標とする可用性によってインフラ構成が大きく異なる

　外形監視は重要。異常に気づけずサービス停止時間が伸びると、目標を達成できなくなる

　99% -> 99.9%にすると、99%のときと比べてコストは25倍程度になる。

  • CloudFrontマジ効きます
  • Blue/Green Deploy or Canary Deployment
    • Rollbackは半自動化
  • 運用フロー
    • 承認を必須とするとダウンタイムが伸びる
    • 事後承認制度等を敷く

　99.99%にすると99%のときと比べ36倍くらいのコストがかかる。

　Multi Regionは本当に必要ですか？リージョン内に複数のAZもあるし、AZ内にも複数のデータセンターがある

　Multi Regionにすると99%のときと比べて47倍くらいのコストが掛かる。

　イベント発生時にシステムで何が起こっているかを分かる状態にしておく。

　「99.999%についてはみんなで検証していきましょう（笑）」

感想

　実例から、運用設計、そしてインシデント発生時の対応設計の重要さを学ぶ内容でした。Well-Architected-Frameworkは数ヶ月前にワークショップを受けに行きましたが、チェックリストとしては有用ながら、迷ってしまうような抽象的な項目が多かったので、その点細かく解説して頂いたのも良かったです。

3つの「Re」〜ソフトウェアの信頼性を高めるためにぼくたちができること〜

　信頼性の高いプロダクトを通じて価値を提供するためには？

  • 信頼性とは
  • なぜチームで働くのか
  • 心理的安全性とは

　信頼性とは、
– トラブルを起こしにくい
– トラブルを解決しやすい
– 変化に強い

　「なぜチームで働くのか？に置き換えてもしっくりくる」

　なぜチームで働くのか
– 複雑な業務、予測不可能な業務に素早く対応する
– 複雑な業務をルーチン化できるなら、自動化すればいい
– 早く進むためには個人、遠くへ進むためにはチーム

　イノベーションの業務
– 研究開発
– 高速な学習ループが不可欠
– 仮説/検証を積み重ねていくのがゴールに達する唯一の手段

　心理的安全性とは
– 誰がチームのメンバーであるか、より、どう協力しているかが重要
– 本来的には、「対人関係においてリスクのある行動をしても、このチームでは安全である」という概念
– カジュアルにやばいことを言える雰囲気

　わかりやすい記事

3つの「Re」

　「3つの「Re」ってタイトル決めた時点では、３つのReがなにかは決まっていなかった」

　責任 Responsibility / 尊敬 Respect / 関係 Relation

　責任 Responsibility

  • 無礼はコストを生む / 礼節はメリットを生む
    • 無礼な人は様々な損害をもたらす
  • 礼節ある態度をとるのは責任
    • 「正しいこと」はそれだけで強い
    • ロジカルハラスメント的な
    • 「正しい」からといって礼節を欠いていいわけではない
    • 「やばいこと」は礼儀正しく伝えよう
  • 自分の機嫌をメンテナンスすることも責任のうち
  • 理想のプロを演じるのが仕事

　尊敬 Respect

  • HRTの原則
    • Humility
    • Respect
    • Trust
  • あらゆる人間関係の衝突は、これらの欠如によるもの

　関係 Relation

  • プロダクトとdevelopersの関係

感想

　信頼性を上げるためには、チームの信頼性を上げることが大事、心理的安全性などチームビルディングに寄った内容でしたが、なかなか本質に沿った素晴らしい内容でした。

まとめ

　全体的に面白いものが多かったのですが、全部聞いてるといろいろなリソースが足りなくなるので、次回はある程度取捨選択しながら行ってみたいと思います。

　展示ブースなどもあり、色々楽しめます。ぜひ行ってみてはいかがでしょう。