YAPC::Kansai 2017 Osaka メモ

@hiratara さんの (メモ)今日はYAPC::Kansai 2017 OSAKAの日です に記録されていないトークのメモです。
（今回の YAPC は3部屋で並列に進行していたため、全てのトークを補完できてはいません。ご了承ください）

また、以下のメモには不足やミスがあるかもしれません。
発見された方は、ご指摘いただければ幸いです。

macOSネイティブアプリ作成におけるPerlの活用 / 野田純生 さん

スライド

• Mac アプリケーション
  • 趣味でやってる
  • ブラウザを作ったり
  • MT のブログエディタ
  • ディスプレイ上の色を教えてくれるソフト
  • WCAG のガイドラインにそった色をつかっているかチェックするソフト(ColorTester)
• Xojo
  • 開発環境
  • 元々は CrossBasic (Basic 用)
  • 今はクロスプラットフォームのアプリ、Web アプリを作れる
  • Single Desktop License 年16000円〜
• Mac ネイティブアプリ の開発
  • Mac = UNIX
  • Xojo で開発
  • OS X 固有のコマンド
    • screencapture
      • コマンドラインからキャプチャがとれる
      • 色検出系のソフトはこれを使って実装
    • say
      • 音声読み上げ
    • mdfind
      • Spotlight のコマンドラインツール
  • Perl
    • Azure のストレージクライアント
      • ネイティブ GUI アプリとして動くが、内部では Perl でファイルのアップロード、ダウンロードをしている
• 開発環境
  • MT 上で開発している(!)
  • MT プラグインで Perl を実行している
  • MT の拡張機能のスキーマビルダーで DB 管理している

ビットコインを5分で試す / ジョエル・デヘスス さん

スライド

• libcbitcoin-perl のインストール
• インストールのやり方
  • Docker コンテナを用意した
  • build して run するだけ
• ブロックチェーン
  • たとえるならデータベースのようなもの
  • P2P ネットワークで保管したり交換したりする DB
  • ビットコインでは MAINNET, TESTNET, TESTNET3 など
    • TESTNET系 を使えば本物のお金を使わずに試せる
  • ブロックの中に前のブロックの情報、番人への支払情報、取引の情報
    • fingerprint がついている
• ビットコイン
  • CBitCoin モジュール
    • XS を使っている ので use の順番に注意
  • 受金
    • deposit メソッドで ROOT/CASH から Bitcoin Address を取得
    • Web サイト上で Bitcoin Address を入力してテスト用のお金を受け取る（TESTNET）
    • 残高も Web で確認できる
    • 取引履歴も見れる
  • 送金
    • ROOT/CASH から ROOT/CHANNEL への移動
      • cash_move メソッド
      • PKI を作る時に ROOT/CHANNEL が必要
    • クライアントが P2P で自分が作った取引記録を送信する
    • 番人が取引記録を受け取るまで
  • PKI
    • 会社の財源とユーザの関係を定めるもの
    • 取引記録の作成
      • OUT 情報、 IN 情報、署名で構成される

Webアプリケーションのキャッシュ戦略とそのパターン / moznion さん

スライド

• Webアプリケーションにおけるキャッシュの話
  • HTTP レイヤー
  • アプリケーションレイヤー
  • 前提：高速なWebアプリケーションを構築、運用していく必要
• キャッシュ
  • 一般的なキャッシュはプロセッサの話
• 今回話さないこと
  • Webアプリケーション以外のキャッシュ
  • プロセッサとかDNSレベルの話
• Webアプリケーションにおけるキャッシュ
  • 一次ストレージより高速なストレージに配置しておいてそれを返す
  • アプリケーションレイヤでキャッシュ
    • 高速なストレージ経由で返す
  • HTTPレイヤでキャッシュ
    • レスポンスを返さない
• アプリケーションレイヤーでのキャッシュ
  • クライアント　→　サーバ　→　一次ストレージ
  • （キャッシュストレージを追加して）
  • クライアント　→　サーバ　→　キャッシュストレージ　→　一次ストレージ
  • キャッシュストレージの方が一次ストレージより高速である前提
  • キャッシュストレージと一次ストレージの値の整合性が保証されている必要がある
  • 今回はこちらのキャッシュの話がメイン
• HTTPレイヤでのキャッシュ
  • クライアントがサーバから受け取ったコンテンツを保持しておく
  • 再度問い合わせの要求が来た時に、クライアントが持ってるキャッシュを使う
  • 古いキャッシュを使ってしまう可能性がある
• なぜキャッシュを使うのか
  • リクエストを高速に返却
    • ユーザ体験をよくする
  • 単位時間あたりの処理数増加
    • 計算リソースの効率上昇
  • 特定コンポーネントの負荷軽減
    • ストレージに負荷が集中するので、キャッシュに逃がして回避する
• キャッシュをどのような時に使うか
  • どうやってもクエリが遅い
    • スロークエリが大量に投げられて負荷が高まる
    • キャッシュに逃がすことで高速化しつつ負荷分散
  • アクセスがとても多い
    • テレビで取り上げられるとか
    • 遅くはないがリクエストが多すぎてつまる
      • もっと高速なストレージで何とかする
  • 外部サービスに依存している
    • サーバ to サーバでやりとりしている
      • 都度リクエストしてると遅い
      • 外部サービスのステータスに依存
      • キャッシュを仲介することで外部サービスへのリクエストを減らす
• キャッシュストレージ
  • memcached
  • Redis
  • BerkeleyDB
  • mmap
  • アプリのプロセス内
  • etc
• キャッシュミドルウェア
  • squid
  • vernish
• キャッシュ戦略
  • とにかく高速に返す
  • アプリを壊さない
  • 依存コンポーネントを少なく
    • 依存コンポーネントが増えると障害点が増える
    • 安易にミドルウェアを増やさない
  • 省メモリ
    • オンメモリキャッシュの話
    • メモリを食う設計を避ける
      • 最初はうまくいきがち
      • ある日突然障害が起きる
    • expire をつけて、永続的にデータを持たない
    • キャッシュが壊れても泣かない
      • キャッシュは壊れるもの
      • 壊れたらまた作ればいい
      • 壊れても問題にならないようにしよう
    • お金をかけすぎない
      • かければかけるほど、利益率が下がる
• キャッシュパターン
  • （パターン名は moznion さんが勝手に決めたとのこと。他の名前がすでにあるかも）
  • Brokerパターン
    • キャッシュにあったらキャッシュから返す
    • キャッシュになかったら一次ストレージに問い合わせる
    • アクセス頻度の高いコンテンツがキャッシュに乗りやすい
    • 省メモリデータの整合性を保ちやすい
    • 最初にコンテンツにアクセスする人は重い
    • キャッシュに乗ってないときに大量にアクセスがくると複数のリクエストが一次ストレージに送られる
    • Cache Thundering Hard 問題
  • Inventoryパターン
    • キャッシュにあったらキャッシュから返す
    • キャッシュになかったらサーバはデフォルト値を返す
    • その裏で一次ストレージに問い合わせて結果をキャッシュする
    • Brokerパターンとほぼ同じメリットがある
    • 最初にアクセスした人にも速く返せる
    • 最初にコンテンツに来た人が正しいコンテンツを取れない
    • デフォルト値をどうするか
    • Cache Thundering Hard 問題
  • Warmerパターン
    • コンテンツ生成時にコンテンツをキャッシュに載せる
    • クライアントはそのキャッシュを参照する
    • ランキングとかに使える
    • 最初からキャッシュ経由でコンテンツを返せる
    • Cache Thundering Hard 問題が解決する
    • コンテンツが生成される系じゃないと使えない
    • ライフサイクルの管理が煩雑になる
    • メモリを使いすぎる可能性がある
    • キャッシュが揮発したらどうする？
  • Pool＆Flushパターン
    • POSTリクエスト型に使う
    • リクエストが来た時にキャッシュに内容をためて、あとで永続ストレージに書き出す
    • 更新系を高速に処理できる
    • プールが壊れたらデータが消滅する
      • 最終的には諦めるしかない
    • データの一貫性を保つコストが高い
• クライアントサイドキャッシュ
  • HTTP Header を用いたキャッシュ
    • クライアントにキャッシュがある状態
      • 更新されてるときはサーバに取りに行くけど、そうでなければクライアントで完結する
  • ローカルの環境内で完結させる
    • そもそもキャッシュではない
    • 閲覧履歴をクライアントに持ってもらったり
    • タイムライン実装をクライアントストレージに持ってもらったり
  • サーバから返さないのが一番
• キャッシュにまつわる問題
  • Cache Thundering Hard
    • expire のタイミングで、再取得のためのリクエストがバックエンドにいくつも飛んでしまう問題
    • 対策・工夫
      • エントリごとに expire の周期をずらす
      • 同一内容のエントリを二重に用意しておいて expire をずらす
  • 同期
    • キャッシュと永続ストレージの同期問題
    • アプリケーションは基本的に永続ストレージに対して更新を加える
      • キャッシュが古くなっている可能性がある
    • ちゃんと同期させようとすると大変
    • キャッシュが壊れると同期取れない
    • 歯を食いしばってやるしかない
  • デバッグしづらい問題
    • やるしかない
      • memcached のためのツールとか Redis のためのツールとか皆持ってるはず
      • ログを仕込むという伝統ある手法
  • キャッシュミドルウェア増える問題
    • ミドルウェアが増えて、障害可能性があがる
    • 安易に増やさないでがんばる
• キャッシュを使うべきではないシーン
  • データ消えると賠償とか
  • キャッシュは消えるものと考える
  • 運用上消えて良いデータなんてない
  • キャッシュを再構築できない場合
    • 再構築できれば問題ない
    • 再構築でいないなら使うべきではない
  • 他にも色々ある
• キャッシュは麻薬
  • 一度キャッシュを使うと戻れなくなる
  • キャッシュは複雑な機構
  • 入れるのは簡単、抜くのが難しい
  • 安易なキャッシュをやめろ
• ちゃんと設計する
  • DBの設計
  • 変なアーキテクチャをやめる
  • 当たり前のことを当たり前にやる
  • スロークエリ
    • テーブル設計をやりなおせ
  • 外部サービス
    • 依存しない方法を考える
• ちゃんと測定する
  • 負荷下がってるか
  • レスポンスタイミング改善しているか
  • たいして効かないキャッシュはただの負債
• キャッシュは麻薬、キャッシュは最終兵器
  • 使わなくてすむならキャッシュをやめよう

Perl to Go / codehex さん

スライド

• Perl モジュールから Go に書き直すときのコツ
• オブジェクト指向
  • Perl
    • OOP
    • パッケージをクラスとして扱う事ができる
    • 継承、ポリモーフィズムできる
    • Attribute::Protected でカプセル化
  • Go
    • OO(not OOP)
    • "Go is absolutely OO"
    • クラスは存在しない
    • オブジェクト指向プログラミングはできない
    • interface を使ってポリモーフィズム：継承
    • struct の private field とメソッド：カプセル化
      • 小文字始まりだと private
• コンストラクタ
  • Perl
    • hashref
  • Go
    • struct
    • New の戻り値がポインタ
      • ポインタを返す理由
        • 想定外の値が引数に入っていたら nil を返すことで異常を表現できる
• メソッド
  • Perl
    • インスタンス内の情報をインスタンスメソッドで変更できる
  • Go
    • 同じことをやるにはポインタレシーバを使う
      • 常にポインタレシーバを使うとよい
• ポリモーフィズム
  • Perl
    • パッケージによって振る舞いを変更する
  • Go
    • 型、メソッドによって振る舞いを変更する
• モジュールを Go で書き直してみる
  • Proclet を Go に移植（Golet）
  • 設定
    • Proclet では hash
    • Golet では struct
      • map だとキーの存在確認、型の確認が必要になる
  • アロケーションをできるだけ抑える
    • Capacity を指定すると速くなる
• Go でプロセスを扱う
  • Proclet
    • サブルーチンを子プロセスで実行する
  • Go で fork できるか
    • 親プロセスがマルチスレッドだと fork をするのは難しい
    • Go ではやめた方がいい
  • Golet
    • exec でコマンド実行
    • コードは親プロセスで context + goroutine
• まとめ
  • Perl と Go でけっこう違いがある
  • それぞれにあった実装をするべき
  • Perl モジュールを Go で書き直すのは楽しい

利用しているBaaSが終了するときにすべきこと または Parse.com の終了と私たちの取り組み / side_tana さん

スライド

• Parse.com
  • BaaS のひとつ
  • iOS, Android その他6つのプラットフォームで利用できる SDK
• ノハナ
  • エンジニア2名で3ヶ月でサービスイン
  • アプリに注力するために Parse.com なぜキャッシュを使った
    • ハードユーザだったので仲良かった
  • 脱出する計画があった
    • 月末に負荷が集中するサービス
      • Parse.com が落ちる
        • リクエストが通らなくなる
      • 重いクエリを減らしたりした
    • とはいえ脱出するのが難しかった
      • DB 、写真データが大量にある
      • ロックインされてた
• 何にロックインされてたのか
  • 機能によるロックイン
    • Parse.com の API
    • Push サービス
    • V8 ベースの独自の実行環境(not node)
    • Analytics サービス
  • データによるロックイン
    • DB に入ってるデータ
    • 写真などのファイル
    • サービス運営してる時に貯まるログなどのデータ
    • プラットフォームの協力がないと難しい
      • REST叩きまくれば
        • DBのスナップショット作ってしまうので時間がかかる
        • 時間がかかってる間に不整合が起きる
• 終わりは唐突にやってきた
  • 2016-01-28 Moving On
  • 1年後に完全終了
  • 3人のチームで脱出
• 脱却エピソード
  • 機能面の脱出
    • API, Push, モニタリング、スケジューリング
    • API
      • node.js で作られた互換APIサーバを提供してくれた
        • parse-server （名前がわかりづらい）
      • Application Hosting 周りはがっつり実装
      • 怖い
      • DNS作戦（使えなかった）
      • プロキシ作戦（やれなかった）
        • リソースの問題
      • リモートコンフィグ作戦
        • アプリから外部の設定を参照する
        • それにしたがってエンドポイントを変える
    • Push
      • iOS はすぐできた
      • Android の GCM
        • デバイストークンがない
        • Parse.com の SDK がいい感じにやってくれてた
        • Parse.com が Push 次に GCM アカウントを設定できるようになってた
          • 先にそっちを直して、それから移行
  • データの移行
    • DB
      • Parse.com が移行ツールを用意してくれた
      • 使えるのかわからなかったので検証した
        • ほぼ問題ない
        • 24時間で同期がきられる
      • 実際に本番でやってみたら、とにかく失敗する
        • スナップショットからのコピーに失敗する
        • 通信が失敗すると、テーブル単位でリトライ、数回リトライしたら勝手にキャンセルされる
        • 3回目でやっと成功
          • 22時間くらいかかった
    • ファイルストレージの移行
      • ツールはない
      • ファイル名しか保存されない
      • ファイルが Parse.com のストレージか移行先のストレージ化どっちにあるか DB ではわからない
      • 同期するしかない
      • Upload Gateway というものが（自分たちで事前に用意して）あったので助かった
• Parse.com のおかげ
  • とはいえ BaaS の利用は借金に近い
  • 速く開発、リリースできる
  • 利用し続けると脱出が難しくなる
  • BaaS より先にサービスが終わったら我々の勝ち
• それでも BaaSを使うなら
  • API エンドポイントのドメインを管理下においておく
  • 脱却まで含めて計画する

PerlのWebアプリケーションをデプロイする時に僕達が考えたこと / papix さん

• デプロイとは
  • システムをサーバに載せ、利用可能な状態にする
• サービスの両輪
  • 開発とデプロイの療法をやる必要がある
  • デプロイなくしてサービスはない
• デプロイの重要性
  • ユーザの体験を損ねないようにやる必要がある
    • できれば無停止で
    • 失敗してサービスが止まるとつらい
• デプロイに正解はない
  • サービスの状況や規模によって最善解は変わっていく
• 良いデプロイ
  • 必要最小限にとどめる
    • 最初から理想を実現するとコストが高い
    • 引き継ぎも大変
    • 業務で使えるように
  • 新しいツールは業務影響のないところで試す
• ちゃんとしたデプロイ
  • 現実と向き合って泥臭い作業をする
• どこにデプロイするか
  • サービスが動くインフラの選定
• なにをデプロイするか
  • サービスの特徴
    • バッチ、ワーカー、ビルドの必要性、ライブラリのインストールなど
• どうやってデプロイするか
  • プロセスの管理
• どんなデプロイにするか
  • デプロイに使えるコスト
    • 構築コスト、実行コスト
  • 自動化
    • 1コマンドでデプロイしたい
    • 自動化しようとすればするほど、構築コストがかかる
  • 無停止の必要性
    • Service Level Agreement
  • 頻度
    • デプロイ頻度はサービス開発初期は重要
• デプロイのビジョン
  • ビジョンが雑だと
    • コストに見合わなくなる
      • そのコストで機能開発できる
• 仕組みを変えるのは難しい
  • 一度作ってしまうとかえるのは難しい
    • 最初からビジョンにしたがってやっていくと良い
• 手動オペレーション
  • 手順書を作る
  • typo などがある
• shell による自動化
  • typo が減る
  • サーバが増えると大変
• Capistrano など
  • 1コマンドで全台にデプロイできる
• ビルドやライブラリインストールしたものを固めてS3にあげておく
• Consul+Stretcher
  • 開発者はConsulにeventを投げれば良い
  • Capistranoで同じことはできる
• ChatOps
  • Botにお願いすればデプロイが動く
  • 進行状況がチャットで確認できる
• CIツール
  • タスクのログが残る
  • Jenkins
    • 最近コードで管理できるようになった
  • Concourse CI
• Mackerel
  • SaaS
  • どのサーバにデプロイするかを選べる
• デプロイとマイグレーション
  • スキーマの変更
• Graceful Restart

カヤックのゲーム開発・運用の「今」 力技と効率化の先に我々が目にしたものとは / macopy さん

• ぼくらの甲子園ポケット
  • スマホゲーム
  • Guild vs Guild 1日4回
    • 1日4回負荷があがる
  • そのほか、ミニゲームイベント
    • 毎日デプロイ、毎日開発
• 話すこと
  • 構成の変遷と DBIC と DateTime.pm
  • ガンガンやってくるイベントを回す手法
  • Jenkins が起こってる話
• 構成の変遷と DBIC と DateTime.pm
  • Strecher
    • オートスケールに対応するため
    • Pull 型
  • リリース当初のインフラ構成
    • シングルマスター・ノースレーブ
      • 管理画面はスレーブ
      • RDS for MySQL
    • Redis Sentinel (ElastiCache Redis はまだなかった)
    • WebApp と Batch 周りは今と変わらず
      • Push 型のデプロイから Pull 型になった
      • ログは結構変わっている（norikra とか）
  • リリース当初の問題
    • 試合が重い
    • ゲームのコンセプトは「試合が面白い」
      • 逃げられない
    • 試合開始10分前にローカルプッシュされる
      • アクセスが4倍になる
      • これが1日4回
    • バッチサーバが重く、試合進行に時間がかかりすぎる
    • DB の負荷で他の API にも影響が
    • スレーブ遅延で管理画面が10分遅れ
    • Redisの転送量
  • やったこと
    • 一番リクエストの多い夜の試合は西日本と東日本の2つに分けた
      • ゲーム内の地理的情報
      • 1日4回 → 1日6回
        • 人間がはりつく時間が長くなる
    • DBIC の Preetch を活用
      • N+1 クエリを見つけて1つのクエリにまとめる
    • Redis にキャッシュしている試合データを圧縮して入れる
      • WebApp サーバで展開する（台数並べられるので結果的に負荷が分散できる）
    • スレーブ遅延は IOPS が足りなかったので IOPS を増やす
      • お金で解決
    • 試合のことでもスレーブで足りるものはスレーブに向ける
  • だいたい DB で困っている
    • キャッシュはできるだけ使わない方針
      • クエリチューニング
      • パーティションによる実行計画の揺れ
      • TEXT 型のカラムにでかい JSON を突っ込むと転送量がはねる
      • RDS のメンテナンス
  • WebApp
    • Perl 5.16.3
      • あげたい
    • Ark, DBIC, DateTime.pm
    • Mouse
  • API はやくしたい
    • DBIC は便利だが遅いし重い
    • 社内には DBIC をやめたサービスもある
  • DateTime.pm
    • 多機能だが生成コストが高い
    • new するより deep copy した方が速い
  • うるう秒
    • DateTime.pm ではビルド時に勝手にうるう秒を入れる
    • コンパイル時にうるう秒を入れてるからユーザにはどうしようもない
    • うるう秒対応する前のバージョンにダウングレード
  • なかったら insert したいしあるならロック取りたい
    • insert しようとすると duplicate
    • イベント開始時に起こりがち
    • データを事前投入するのが単純に効果的
      • その後に作られたチームに対応できない
• ガンガンやってくるイベントを回す手法
  • イベントを14並列で開発している
  • このパイプラインを滞りなくスムーズにやるには
    • 覚悟と気合
    • 覚悟
      • サーバにデプロイされるものは全てサーバエンジニアが目を通す
  • サーバにデプロイされるもの
    • Perl のコード
    • マスタデータ（CSV)
    • Unity がよむ Asset Bundle
    • chef のレシピ
    • ↑ 上記全て PR 作ってサーバエンジニアのレビューを通す
  • ブランチを切る BOT
    • 定型の命名規則とブランチツリーを持った topic ブランチを自動生成する bot
    • 簡単に PR 作れるようにすると、 "No description" が多発する
      • 解決方法
        • ポエムを書いた
        • Wiki に PR を作るときの心がけを書いた
        • 書き方の例を示す
  • マスタデータ
    • ユーザに変更されないデータ
    • CSV でデプロイ時に DB やクライアントに渡す
    • スプレッドシート
    • スプレッドシートから CSV に変換する
    • スプレッドシートのブランチ管理
      • 差分管理
• 開発環境
  • 開発サーバ
    • 増える
    • dev01,dev02,dev03,...
    • スプレッドシートで管理しはじめる
    • 無限に立てたい
  • Docker
    • Docker で環境分離してホスト名をミラージュでつけることで、リソースがある限り無限に開発環境を作れる
    • ディスクは有限
    • メモリ、CPU も有限

Perl 6 で Web Application Framework をつくる / astj さん

• Perl 6
  • Larry Wall がデザインした Perl 5 っぽい夢の言語
• WAF
  • ウェブアプリケーションの土台や必要になるものを用意してくれる
  • PSGI
    • リクエストの詰まった hash をうけとって array ref を返す
  • Perl 6
    • P6SGI
      • PSGI とほとんど同じ
    • Crust
      • Plack の Perl 6 版
• 目指すもの
  • Sinatra like な軽量フレームワークのコンセプト実装
• Sixatra
  • Crust::Middleware 使いたいので Crust Toolkit 上でやる
  • フィルタ(before, after)
    • 間に合わなかった
  • セッション
    • Crust::Middleware::Session
  • 静的ファイル配信
    • Crust::Middleware::Static
  • DB 接続層
    • 20分で収まらないので今回は話さない
  • コードジェネレータ
• ルーティング
  • Router::Boom::Method

H2O x mrubyで人はどれくらい幸せになれるのか / @i110 さん

スライド

• H2O
  • なぜ高速なのか
    • 優先度制御が優秀
    • 先進仕様への対応の速さ
    • neat かつ無駄のない実装
• Apache と nginx つよい
  • 豊富なモジュール群
  • 情報の多さ
  • 枯れてる度
• 便利で快適な Web サーバへ
  • Apache や nginx にできて H2O にできないことをなくしたい
    • モジュールを増やしたい
    • ユーザが拡張モジュールを書きやすいようにしたい
  • Apache や nginx と同じことが簡単にできるようにしたい
  • ドキュメント書くようにします
• 組み込み言語として mruby を採用
  • 想定用途
    • アクセス制御、URI リライト、レスポンス書き換えなど
    • プログラマブルで柔軟にかける
• サーバ機能の拡張性
  • Cloudbleed という CDN で発生したユーザ秘匿情報の漏洩位問題
    • nginx モジュール（HTML パーサ）のバグ
    • mruby で書けば原理的に発生しなかった問題
• 設定の柔軟性＆テスタビリティ
  • Apache や nginx のディレクティブを覚えられない
  • "apache config not working" で検索すると約1000万件
  • Apache や nginxだと設定は複雑なのにテストがかけない
  • mruby ならテストが書ける
    • 単体テスト、スタブを使ったテスト
• H2O x mruby の仕組みの簡単な解説
  • H2Oのアーキテクチャ
    • マルチスレッドｘイベントループ
      • デフォルトでコア数と同じ数のスレッドが起動する
      • スレッドがイベント駆動でリクエストをさばく
    • I/O 絡みの処理はノンブロッキングで処理
      • mruby 中の処理もノンブロッキングでやりたい
        • 既存の mrbgems では簡単にブロックする（redis.get など）
        • イベントループ対応された既存 mrbgems はほとんどない
        • コアの方が歩み寄ってくれないと厳しい
        • → Fiber：コルーチン・継続・協調マルチタスク
  • H2O と mruby でできること
    • アクセスコントロール
      • v2.1 から acl という組み込みメソッドを用意してアクセス制御が簡単にかけるように
      • nginx だととてもつらい（Apache でも）
    • DoS Detection
      • 標準で DoSDetector というライブラリを提供
      • Dos 検知
      • Apache の mod_dosdetector に相当
      • カスタマイズ可能
    • HTTP Request
    • Redis
      • TLS Session Resumption のバックエンドとして使うためネイティブでサポートしている
      • mrubyでも使えるようにしたい
• 知られざる機能
  • ステルスで追加した機能
  • 近々マージ予定の機能
    • 次のリリース(2.3)で入りそうな PR がたくさんある