背筋を伸ばしてスタートアップするブログ

株式会社ペライチでCTOをやっています。

builderscon tokyo 2018に参加して丸2日間色んな技術を学んできた

イベント 勉強会 技術

あとで読む

buildersconというカンファレンスに参加してきました。

builderscon.io

2018/09/07(金)〜2018/09/08(土)の2日間で開催されていましたが、両日ともためになる内容が沢山聞けて個人的にとても充実したカンファレンスでしたでした。この記事では2日間で受けた全てのセッションのメモを残そうと思います。

Kubernetesで実現するインフラの自動構築パイプライン

builderscon.io

  • cybouzのインフラ
    • 物理サーバー1,000台以上
    • インフラのためのPythonコード100,000以上

  • よくある自動化の流れ

    • 人が手でオペレーションする
    • オペレーションの回数が増えてくる（辛い）
    • 手順をPythonスクリプトにして自動化

  • スクリプトを実行するための前提条件が難しい

    • 前提条件を満たすために人が頑張る
    • 考慮漏れがあると障害になる
  • 手順ベースの自動化のつらみ
    • 「手順」は差分的
      • 現在の状態と理想の状態の差分
    • 手順をそのまま自動化すると脆いシステムになる
      • 現在の状態がちょっと変わっただけで動かなくなる
      • ちゃんと前提条件を満たせているのかどうかが不安
    • ではどうすればいいか
      • 理想状態への収束
        • 理想状態をシステムに与えると現在の状態との差分を自動的に抽出し、必要な手順を勝手にやってくれる
  • プロダクトのAWS移管を機にスケールするインフラづくりを目指した
    • 「理想状態への収束」をするためにKubernetesを利用

手順書運用のなんとなく辛いと感じてた部分を言語化してくれててスッキリした。組織やプロダクトが常に変わり続けるようなWebサービスづくりをやってると前提条件が変わって手順書がすぐ使えなくなってしまうというのはすごくよく分かる。Kubernetesの具体的な話に関してはこちらの知見が少なくあまりピンとこなかったので、Kubernetesの情報収集してからスライドを見返そうと思った。

開発現場で役立たせるための設計原則とパターン

builderscon.io

※ スライド資料が見当たらなかったので図解してくれてる方のツイートを貼っておきます

nekogata.hatenablog.com

[追記] スライドがアップされました！

  • 設計とかパターン
    • 議論が空中戦になりがちで、発散しがち
    • 責務って考え方次第
    • 「DRY原則」→Utilクラス誕生→「Utilクラスは糞」→どうすればいいの？？？？
  • 設計とは
    • ある問題に対して解決策となるような構造を与えるためのアクティビティ
    • 複数の分割構造の選択肢から最適な選択を選び出すこと
      • ここで設計原則やデザインパターンが武器になる
  • デザインパターンと設計原則
    • デザインパターンとは
      • 分割構造とその実現方法のカタログ
    • 設計原則とは
      • 分割構造が良い構造かどうかを判断するための指針
      • 一回構造をつくって終わりじゃなくて、設計原則を使ってレビューして、さらに再構築する
  • あかん
    • なんであかんのか言語化できますか？
      • できなければそれは暗黙知
      • ちゃんと設計レビューなどで言語化できた方がいい
      • 根拠がもってレビューしよう
  • 重要な設計原則
    • 単一責任原則
    • 解放閉鎖原則
    • 凝集度と結合度
  • 単一責任原則
    • あるクラスを変更する理由がふたつ以上あってはいけない
    • 変更Aと変更Bのどちらからも影響を受けるクラスはだめ
    • 逆にいうと「どこが変更されるか」が分からないと単一責任原則は使えない
    • 「どこが変わりやすいポイントなのか」を見極める必要がある
  • 解放閉鎖原則
    • 拡張に対して開いている
      • 機能拡張、機能追加するときに他のクラスに影響がないようにしよう
    • 修正に対して閉じている
      • 内部を修正したときにそのクラスに依存しているクラスに影響がないようにしよう
      • あるモジュールを修正するときに、その呼び出し元も修正しなきゃいけないのはだめ
  • 凝集度と結合度
    • 凝集度は高く
      • 関連するものはひとつにまとめる
      • ひとつの仕様変更でいろんなクラスに影響しないようにしたい
    • 結合度は低く
      • 片方の影響がもう片方に出ないようにする
  • 設計は「問題」次第

  • 抽象化しない勇気を持つ

    • KISS原則
    • YAGNI原則
      • どこが変わるかわからないときには現在分かってる範囲のみで極力シンプルにしておくべき

  • おすすめリポジトリ

    • EnterpriseQualityCoding/FizzBuzzEnterpriseEdition
      • どこが変わってもいいように書かれたFizzBuzz．問題を捉えそこねた抽象化を重ねた結果ひどいことになっている
  • まとめ
    • 複数の選択肢を持つ
    • 変わりやすい場所を見つけ出す
    • 問題に対して適切な設計原則を適用する

一番聞きたかったセッションだけど期待通りめちゃくちゃためになる内容だった。コードレビューや設計レビューをする際、既存のソフトウェアのつくりにフォーカスしやすいけど、未来の仕様として「変わりやすいポイント」がどこなのかを予測しながら設計を考えるのが大事だという話は非常に納得感があった。問題を捉えそこねた上で設計原則しても意味無いというのもすごく同意。一概に◯◯原則を適用すればいいというものでもなくその前段階に何が問題なのかを見極める癖をつけていきたいと思う。

知らなかった時に困るWebサービスのセキュリティ対策

builderscon.io

  • 実例
    • カラーミーショップで実際に起きた情報流出インシデントの実例を交えたセキュリティについての話
    • 不正プログラムを設置された
  • 情報セキュリティ
    • 以下3つのうち一つでも損なわれるとセキュリティインシデントになる
    • 機密性: 盗まれない見られない
    • 完全性: ぶっこわされない
    • 可用性: 落とされない
  • 基本的な概念
    • 脅威
      • インシデントを引き起こす可能性のある要因
    • リスク
      • 脆弱性に漬け込むことによって組織に損害を与えることの影響
    • 脆弱性
  • 入口
    • 不正ファイル識別不足
      • ファイルのアップローダ部分の機能にPHP, CGIプログラムが含まれていないかを検証する機能を実装する
    • Webアプリケーション侵入に対する対策不足
      • WAF
  • 出口
    • ロギング不足
      • データベースに対するクエリログ
      • ログはFluentdを使ってS3に集める
  • 体制の強化
    • セキュリティ対策室の設立
  • ISMS（情報セキュリティマネジメントシステム）
    • チームでPDCAをまわす
  • ISMSのコスト増は確実にある
    • 全部は対処できない
    • 適切なリスク評価によって優先順位を決める

実例を交えたリアリティのある話が聞けて面白いセッションだった。改めて思ったのはセキュリティ対策は組織づくりとセットであるということ。インシデントにつながる脆弱性情報のキャッチアップもそうだし、インシデント発生時の対応は日頃からチームとしてポリシーを決めてリスク管理しておくことが大事。

機械学習を用いず数学でゲーム内の需要予測する

builderscon.io

（資料公開待ち）

  • 4つの分析
    • 記述的分析: 過去や現在を知る
      • BIツール
    • 診断的分析: 因果関係を見つける
    • 予測的分析: 未来を知る
      • 機械学習
    • 処方的分析: 未来をコントロールする
      • 機械学習
  • ex 1ヶ月に1.02倍の成長→2年後には2.03倍になる
  • 正しくデータを解釈できるようになるためにはどうすればいいか？
    • 数学しようぜ
  • 数学者がやっていること
    • なぜの追求
      • 曖昧な理由（主観的要素）を排除し客観的な正しさを求める
      • 数値化することで客観性を担保する
      • 主観に基づく認知バイアスを取り除く
    • 数値と言語の行き来
      • 藤沢数希
        • モテ = 試行回数 * hit ratio
        • hit ratioはどんだけ頑張っても1なのに対し、試行回数は無限。
  • ソシャゲ運用あるある
    • ex 新規ガチャめっちゃ売れた→ 復刻したときも売上期待できそうだ！→売れない。。
  • 未来予測の流れ
      1. 前提条件とゴールの設定
      2. ex. ゴール: 現在のデータから次回のがちゃがどれくらい回るのかを予測する
      1. データを眺める
      2. 統計的にどれくらいのサンプル数を見れば十分かは求められる
      3. 所詮有限な数なので5000くらいは気合で見る
      1. 仮説作成
      2. ドメイン知識が重要
      1. 仮説を数値に落とし込む
      2. いきなりフィットすることはないので最初は最小値と最大値が合うような一次式を組み立てる
      3. 端点さえあっていれば中身はあとでいくらでも調整できる
      4. スキルレベルごとの所持人数をカウントしてそれに重みをつけた一次式を調整する
      1. 例外処理・微調整
      2. 土台となる式ができても2,3割くらいは実際の値からかけ離れていることがほとんど
      3. どのデータがずれているのかひたすら観測する
      4. データ数が少ないと特にデータがぶれやすい
    • ゴールと相関のある数字を見つけて例外をひたすら潰していく
  • 機械学習にも挑戦したけど全然うまくいかなかった
    • 過去データがとれない
    • データの前処理を先にやらないといけない
    • 十分なデータがない

思ったよりがっつり数学の話だったけど数学を扱う人の生態系に触れられて面白かった。未来予測をどうするかの話は具体的な手順が分かりやすくて、うちのグロースハックチームで題材作って試してみたい。

次世代通信プロトコルにおけるセキュリティ・プライバシー保護・パフォーマンス

builderscon.io

  • 自己紹介
    • FastlyでOSS開発者をやっている
  • ネットワークを信頼していいかという議論がここ最近巻き起こっている
    • スノーデン
    • みんな会社のWiFiだけじゃなくてパブリックなWiFi使ったりしてる
  • アジェンダ
    • TLS1.3
    • QUIC
  • TLS1.3がどういうものか
    • ほとんどメジャーバージョナップ（TLS1.2からガラッと変わってる）
    • 再接続する場合は0回
    • AES-GCM
      • 認証付き暗号化をやっている
      • AES-CTR
      • 問題としてはnonceを1回しか使えない
  • TLS1.2のハンドシェイクプロトコル
    • やりとり
      • パラメーター
      • 証明書
      • 公開鍵
    • 問題点
      • やりとりを2回繰り返さないと暗号化できない
      • 証明書から誰と通信できるかバレてしまう。大規模なトラッキングができてしまう
  • TLS1.3のハンドシェイクプロトコル
    • サーバーはクライアントからリクエストを受信した瞬間からアプリケーションデータを送りはじめることができる
    • 証明書が守られている
  • 標準化まで時間がかかっていた
    • 企業向けのファイヤーウォールで通信を切られていた
    • TLS1.3だと証明書が暗号化されているから、誰と通信しているかがわからないため
    • TLS1.3を通せないgatewayがあったために、普及に時間がかかった。TLS 1.2の再接続要求に見えるようにフローを変更
  • QUIC
    • 暗号化されたトランスポートで、ハンドシェイクにTLS 1.3を利用。
    • トランスポート層で複数のコネクションをまとめる機能、先頭のパケットが落ちても後続のデータが読める
    • QUICだと、ネットの接続先が切り替わっても接続が来れない
    • QUIC+TLS1.3だとHTTP+TLS1.2より通信の往復が少なくて済むのに加え、攻撃耐性ができる
  • まとめ
    • プライバシーを侵害するような攻撃はほぼ防げるようになる
    • 暗号化は可用性のため、プロトコルの硬直性のためにも使われるようになる

専門ではない話が沢山でてきてセッション全体的に正直理解度5割くらい。ただ、通信インフラ面でどういう技術開発が行われているかをキャッチアップするという意味ではすごくよかった。社会的に現行のネットワークの信頼性に議論が生まれているというのは納得。TLS1.3やQUICというプロトコルの仕様策定や実装に関わってるからこそ話せる内容だと思うので貴重な機会になった。

すべてがgemになる - サービス密結合からの段階的脱却

builderscon.io

  • 概要
    • 2つめ、3つめの既存サービスとデータを共有するサービスを作るときにどう連携するか
  • サービスの構成
    • Wantedly
      • メインサーバ
      • 全サービス共通のユーザー認証サーバ
    • マイクロサービス
    • マザーRails
      • コアなドメインを扱うサーバはRails
  • サービス密結合は何が悪いんだっけ？
    • ex. メイン◯◯サーバーの共有→相乗りする
    • うれしいこと
      • 既存の資産を存分に
      • サーバがいっぱいあるとつらいことが多い（エラーハンドリング、リトライ）
    • いやなこと
      • 障害起きたときの問題の切り分けが難しくなる
        • 影響範囲を調べるのに両方の知識がいる
      • 下手すると巻き添え食らって両方落ちる
        • 共有サーバーが単一障害点になる
      • モデルが混ざる
        • app/modelsをぱっとみてどれがどっちのサービスなのかわからない
        • 実現したいことが似ているからといってサービス間でモデルまで共有するとさらに見極め困難になる。変更するときの影響範囲の判断が困難に。
  • 共有サーバーが落ちたのをきっかけに密結合を離すことに立ち向かった
    • ドメイン定義
      • DDDの本読んだ
    • 移行先サーバーづくり
      • 新機能は全部新しいサーバーに
      • これにより新機能追加を不安なく行えるようになった
    • コアモデルを新サーバーから触れるように
      • 特定のデータの読み書きにどうしてももとのサーバーを経由してしまうためつらい
      • Rubyならgemにすれば生産性を下げずモデルを共有できるのではないか？
  • モデルをshared gemにした話
      1. DBを共有する
      2. マイクロサービスでは1つのDBを複数サービスが参照するのはアンチパターンだが、今回はモデルが共有される、ActiveRecord経由のみで読み書きするためよしとした
      1. 切り出し対象を決める
      2. 切り出し対象の中心になるモデルを決める
      3. 関連するモデルやサービスをクラス図とか書く
      4. fluent loggerなどを使ってログ収集してもいいか
      5. 切り出し対象のコードを決める
      1. 切り出し方（gem化のやり方）を決める
      2. 共有部分を新しいリポジトリに切り出す
      3. そのままgemにするとデバッグがしづらくなる
      4. gemの中身をすべてシンボリックリンクにしてしまう
      5. 実体はもとRailsのapp以下においておく

開発スピードを落とさずに、数年後に後悔しないで済む設計をするためにどうするかの話。うちもサービス拡大に伴ってどのようなアーキテクチャにするかは悩むポイントなので他人事じゃない感じで聞いてた。マイクロサービス化しながらDB共有するってかなりドラスティックな変更だと思うので、APIじゃだめだったのかなどもっとメリット・デメリットについて突っ込んで聞いてみたいと思った。もっとメリット・デメリットについて突っ込んで聞いてみたいと思った。

ブログサービスのHTTPS化を支えたAWSで作るピタゴラスイッチ

builderscon.io

  • はてなブログの独自ドメインを常時HTTPS化にした話
  • 現在万単位の独自ドメインが登録されている
  • Let’sEncryptを利用
    • APIで利用可能な認証局（CA）
  • Let’sEncryptの登場は朗報だけど、これだけだと足りない
  • 万単位のTLS証明書を管理する戦術、戦略が欠けている
  • HTTPS配信
    • 一般的なWebサイト運用の感覚だとなーバスすぎる
    • 万単位の証明書を一度に読み込むとproxyのメモリ使用量が著しく増加する
    • proxyの再起動にも時間がかかる
  • SANを利用するか？
    • Subject Alternative Names
    • 1つの証明書に複数ドメインを紐付ける拡張
    • 結論から言うとはてなブログでは難しい
      • LEでSANを利用する場合ACME challengeはdns-01のみしか利用できない
      • DNS設定は各ユーザーに委ねられるので自動化できない
  • ACMEとは？
    • 証明書発行などの作業を自動化するプロトコル
    • Let’sEncryptが主導
    • dns-01: ドメインのTXTレコードにワンタイムトークンを書き込む
    • http-01: CAのリクエストに対し所定のレスポンスを返す
  • 証明書発行
    • 一貫性・網羅性が求められる
    • 発行に失敗するとブログが閲覧できなくなる
    • 要求は高いが不確実性は高い
    • 証明書を更新する際、ドメイン数に対してスケールすること
  • 無効なドメインの削除対応
    • ACEM challengeに必ず失敗する
    • 放置するとAPI limitにあたってしまう
    • そのため失敗したドメインは必ず削除する
  • 実際にできたシステムの紹介
  • 配信システム
    • ngx_mruby: 証明書読み込み時にmrubyのコードを実行
      • cache gatewayへhttp getするだけ
      • リクエストごとに証明書を取得
    • AWS(DynamoDB)API呼び出しをHTTP APIに帰る
      • mrubyにはAWSSDKがない
    • 同居するmemcachedにも読み書きしてDynamoDBへの書き込みをへらす
  • 証明書発行システム
    • AWS StepFunctions
      • 処理の実行順を管理、エラー処理、Lambdaを実行
      • エラー内容に応じたリカバリ・リトライ
    • AWS Lambda
      • 証明書を発行、DynamoDBへ書き込み
    • はてなブログのボタンを押すとStepFunctionsが起動。Lambdaが起動しLet’sEncryptにACMEチャレンジを行い成功したらDynanmoDBに保存
  • 証明書定期更新
    • DynamoDBの「TTL Trigger」がLambda経由でSFnを起動
    • cert-reissue-confirmer: はてなブログにドメイン有効性を問い合わせて更新する必要があるかどうかを後続に伝える
    • DynamoDBのTTLTrigger機能について
      • TTL expire を DynamoDB ストリームのトリガーで掴む
  • ぼくのかんがえたさいきょうのピタゴラスイッチ
    • ワークフローエンジンの導入
      • AWS StepFunctionsとそれから実行されるAWSLambda
    • pub/subモデルで対象データの増加に対しスケールさせる
      • pub/sub: DynamoDBとTTLTrigger
  • Q&A
    • 更新失敗時の対応は？
      • DynamoDBを2種類用意して、TTLをそれぞれ分けている。 具体的には実際の期限前の2週間前くらいにしている。StepFunctionsの結果を取ってきて、Mackerelに通知するようにして、その猶予の間に手動などで対応する

うちでもまさにLet’sEncryptを使った独自ドメイン管理の自動化を行っていて比較しながらの聞けたのですごく勉強になった。ドメイン数が今後スケールして多くなっていったときにいかにスケールに耐えられる構成にするかいう視点でAWSのフルマネージドサービスに寄せるのは正しい選択な気がする。DynamoDBの機能など知らないこと多かったのでもっと勉強しようと思った。

つらくないマルチテナンシーを求めて: 全て見せます！ SmartHR データベース移行プロジェクトの裏側

builderscon.io

  • SmartHRのデータベース移行プロジェクトの話
  • もともとの問題
    • スキーマ変更のせいで時間がかかりすぎる
  • マルチテナント
    • 複数の企業が同じWeb/DBサーバーを共有する（利用企業からみると専用）
    • 計画資源を共有しつつデータの分離を実現
  • なぜやるか？
    • インフラにお金がかからない
  • Railsのマルチテナントgemを採用
    • 「apartment」というgem
    • テナントが作成されると、MYSQLならCREATE DATABASEが実行される
    • 生成された対象に向けてスキーマ定義を適用
  • apartmentの落とし穴
    • 全然関係ないけど去年台湾のRubyカンファレンスで「apartmentを使うな」という発表ｗ
    • DBマイグレーションにかかる時間の増大
    • データベースの起動にかかる時間の蔵絵代
    • ActiveRecordのキャッシュでメモリどか食い
  • マイグレーション問題
    • 1テナントあたりマイグレーション1回。10000テナントなら10000回
    • これのせいで100時間とかかかる
  • 週1〜2ペースでマイグレーション実施してた
    • サービスリリース後徐々に顕在化するデプロイ問題
    • Webコンテナのデプロイは終わってるのにmigrationのデプロイが終わらず500エラーに
    • それを解消するために並列実行をやめたら時間がかかるように。。。

  • 問題の整理

    • 並列デプロイは実践投入されたばかりで不安定

  • 解決策

    • 金の弾丸
      • インスタンスはケチっちゃだめ
    • 優先マイグレーション
      • ログイン回数が多いユーザーや、課金ユーザーを優先的にマイグレーションする
  • Citus
    • オープンソースのPostgreSQL拡張
    • 高いスケーラビリティ
    • クエリ並列化のための分散エンジン
    • とにかくマイグレーションが速くアプリケーションからは単一のDBのようにみえる
    • Citusに移行
  • 移行に伴いコードフリーズ
    • 機能開発しながら移行はきつい
    • 5〜6月にかけて本体の開発を一ヶ月停止しますと全社通知

  • 最終的に100時間のデプロイが23秒に。

  • Q&A

    • 移行後のデータが壊れていないかどうかの検証どうしたか？
      • よくこけるデータは決まってるので、テストテナントで確認
    • 会社としてコードフリーズができた要因は？
      • プロダクトオーナーは開発チームの会話の中にいつもいるので、理解してもらいやすかった

マルチテナント構成のつらみとそれが巻き起こすデプロイに関する問題を解消するための壮絶な戦いの記録を聞いたという感じで発表後の満腹感がすごかった。サービスのユーザー価値に直接的に寄与しない開発にこれだけの労力を時間をかけて粘り強く取り組んで改善できたというのは素晴らしいと思う。特にコードフリーズの判断は会社としても強い意志を持たないとできないことなので、開発のつらみの空気を事前に共有できてるのはすごくいいことだなと思った。

RDB THE Right Way ~壮大なるRDBリファクタリング物語~

builderscon.io

  • RDBの正しい道とは？
    • RDBの正しい設計
    • RDBと付き合っていく上でどうやって正しい道を歩いていくか
    • DBの寿命はアプリケーションより長い
  • モデリングをするために必ずするべきこと
    • データと情報は違う
    • SQLアンチパターンのまえがき
      • 画面に表示するのは情報
      • 情報には目的がある。データは単なる事実
      • データを永続化して蓄えるのに適しているのがRDB、それから情報を生成するのがSQL
    • データ設計と情報設計は分けることが大事
      • Railsとかになれてると、混在しがち（1table1model）
      • データ設計: 事実をどのように記録するか
      • 情報設計: 事実をいかに加工・利用するか
  • 情報優先でデータ設計をするとデータに矛盾が生まれる
  • ではどうやって設計していくか
    • まずモデリングをする ← めちゃくちゃ大事！
    • いきなりデータ設計せずにER図を書く
  • Entityを定義する
    • Entityとは
      • イベント（コト）
        • 事実
        • 5W2HのうちWhenとHow to
      • リソース（モノ）
        • 事実を生み出す元、未来、概念
        • WhenとHow to 以外
  • Entityを関連付ける（リレーション）
    • リレーショナルモデルで定義 → 正規化
    • モデリングの前に正規化 → ✕
    • データに矛盾があるというのは正規化できていない
  • 論理設計と物理設計
    • モデリングせずにいきなりテーブルを考え始めるのはいきなり物理設計してるということ
    • 物理設計
      • データをシステムとしてどのように保存するか
  • 正規化で生じる問題
    • パフォーマンス問題
      • JOIN地獄etc
    • アプリケーションの制約
      • ID必須なのはアプリケーションの都合（ORマッパーの都合）
      • フレームワークの都合でDBマイグレーションが外部キー制約に対応していない
    • システム・アーキテクチャの制約
  • データは常に成長する
    • 量は増え質が変化する。正しさを常に問うて設計を変化させていく
    • データベース実践入門おすすめ
  • リファクタリング
    • データベースの不吉な臭い→技術的負債
      • チーズと腐った牛乳の違い。一緒くたに技術的負債にしてしまわないように判断する
      • スーパーテーブル作ってませんか？
        • ex. 婚活サービスでいうpartiesテーブル
          • 公開前のパーティー、公開中のパーティー
        • 値によって意味が変わる
        • 特定の列の値で他の列の値の意味が変わる
          • EAVというアンチパターン
    • SQLアンチパターンを読もう。今すぐ読もう
  • DBテーブルを把握する上でおすすめの方法
    • table一覧を眺める会
      • チーム全員でただテーブルを眺める
        • 誰も知らないテーブルとかが出てくるｗ

DB設計についてすごく丁寧でわかりやすい内容のセッションだった。論理設計と物理設計を一緒くたにせずきちんとデータと情報を分けてモデリングしてから進めるという話意識しないとできてないケースも多い気がする。データベースの寿命は長いからこそより設計に力を入れるべきというのは納得感ある話だった。とりあえずSQLアンチパターンはすぐ読もう。

その他聞きたかったけど聞けなかったセッション

スライドへのリンクだけおいておきます。正直パフォーマンス計測の話はめちゃくちゃ聞きたかったけど、断腸の思いでAWSピタゴラスイッチを選びました。後悔はしていない。けどめちゃくちゃ気になる。。再放送してほしい。

まとめ

今回初参加だったけど、どのセッションも中身が濃く聴講するだけですごくカロリー消費するような内容でした。とても楽しい2日間をありがとうございました。登壇者、運営の皆様お疲れさまでした！