#ISUCON 5が面白かった話

チーム友利奈緒です。

ISUCON5に参加してきました。

事前準備

急に参加することが決定したのでGCPのセットアップ程度で、事前の予習などはウェブ上の記事程度になってしまった。 これが結構痛くて、今となってはISUCON慣れしておく必要があったと後悔しています。

当日

言語はRubyで、自分の担当は主にアプリケーションコードの修正の担当をしていました。

午前まずやったこととしては、rack-lineprofで行数レベルで処理時間が長くかかっている箇所を特定し、チームで共有することをしました。 あとはチームで全体の構成を見たり、テーブル構成を見たりして、問題の洗い出しをしていました。

午後はテーブルにインデックスを張ったり、UnicornやNginxの設定見直しやN+1クエリを潰したり、一部Redis化したりしていきました。お昼すぎくらいまではTOP20に入るくらいのスコアは出ていました。しかし夕方に差し掛かるにつれて、だんだん煮詰まってきました。

ここででたまらずCharlotteを流し始める。

やっぱり友利奈緒なんだよな〜と言いつつfootprintsテーブルをRedis化し始めるも時間が足りず、結局スコアは伸びませんでした。

感想

反省としては行き当たりばったりの修正が多かった気がするので、少し我慢して着手し始める前におおまかにやることを洗い出す。そしてだいたいの方針を固めて、もう少し共有しながら進めていったほうが良かったのではないかと思います。 あとは、ベンチマークが走っている時のログや、topなどを見ずに夢中でコードを書いていたので、その辺りも見ていくべきでした。

とにかく面白かったし、何より悔しかったです。 問題が出され、解答してスコアが出る。これだけでもすごく面白かったですし、自分の実力がスコアとして、対外的にわかるというのはとても刺激になりました。

また今までは、参加せずに様子を眺めているだけだったのですが、実際に参加してみると想像以上に良かったです。 8時間チームで集中して協力して、問題を解く。終了後に反省会、感想戦をする。他の参加者の知見を得るというのが本当に勉強になるし、面白かったです。

技術的には、実装のアイデアとスピードがまだまだでした。もっと貢献できるように頑張ります。 一年間修行して、また再び挑みたい。

Shibuya.ex #1 の様子

Shibuya.ex #1 - Shibuya.ex | Doorkeeper

参加してきました。スライドの簡単なメモとツイートをピックアップして載せておきます

Elixirご紹介（@naoya_ito さん）

speakerdeck.com

ざっくり特徴

  • ErlangVMの上で動く
  • 最近の言語的なトレンドがある
  • 軽量プロセス、アクターによる並列処理
  • Rubyっぽくない
    • 似てるのはdefとdoぐらい
      • ユーザフレンドリー

なぜElixir？

  • ランタイムが強力
  • 重要なのはErlang/OTPの上に乗っていること

関数型

  • 動的型付けの関数型言語
    • なし
      • 静的型付け
      • 純粋関数型
      • 部分適用、カリー化
      • オプション型（Maybe）
    • ある
      • リスト内包表記
      • 遅延評価、無限リスト

参考

次の10年の為にElixirをハックする（@mizchi さん）

speakerdeck.com

Elixiriはどういう言語か

  • 文法は気持ちの問題
  • すぐにErlangを学ぶハメになる

Elixirへの不満

  • いまさら型がない言語を学ぶこと

Elixirに解決して欲しい問題

  • Let it crashしたい
  • GCセンシティブ

本音

  • つまらない言語で消耗したくない
  • Elixirみたいな面白機能積んだ言語流行ってくれ

割り切り

  • Erlangは結局Network DSL言語として割り切ったほうが良い（by @voluntas）
  • CPUヘヴィが速くなるわけではない

Elixirを本番環境で使ってみた事例紹介（@ohrdev さん）

www.slideshare.net

サービス紹介

  • DreeVee

採用の経緯

  • 旧システムはRails
  • やりたいこと
    • 大量のリクストを安全
    • サーバコスト
    • スケール
    • サービス止まらないように
  • 候補

どう使っているか

  • API部分に限定
  • バックエンドはRedis、Dynamodb
  • デプロイ
    • exrm
  • maru
    • grapeのelixir実装
  • その他
    • exredis, poolboy, ex_aws, rave_elixir

困ったこと

困らなかったこと

感想

  • Erlangを知らないと辛い
    • エラーログはErlangベース
    • ErlangをRubyで書いている感じ
    • ElixirのライブラリはまだErlangのラッパーがほとんど
  • ドキュメント少ない
  • コミュニティが少ない
    • sapporo.beamおすすめ
  • Erlangのコミュニティ、エコシスエテムは偉大
    • 時雨堂さんのドキュメントが参考になる
  • Elixirならではの機能が便利
    • パイプ演算子がないとやっていけない体に
    • struct、protocol、遅延処理、etc
    • マクロが強力
  • debug、Perf関連はErlangのプロダクトが充実
    • observer、eper、
    • Elixirも徐々に充実
  • Erlangをざっと把握しておくと良い

Cowboyを使ってみる（@hayabusa333 さん）

www.slideshare.net

Cowboyとは

  • モジュラー形式のHTTPサーバ
  • ErlangVMで動くHTTPサーバとしては一強
  • Plugを使えばもっと簡単

DBにseedにするライブラリつくった（@Joe-noh さん）

www.slideshare.net

exseedがある

要望

  • モデル名繰り返したくない
  • 1行1属性縛りは避けたい
  • 複数Repo使えたい
  • Elixirらしく、パイプを使いたい

    tane

Rails TutorialをPhoenixで移植してみた（@hagiyat さん）

speakerdeck.com

Elixirのライバル達を紹介する（@moccos さん）

speakerdeck.com

Fantasyスタックの話（@yodatomato さん）

おわり

Shinjuku.ex #10 行ってきたメモ

shinjukuex.connpass.com

新宿で迷子になっていたので、2つめの途中から参加しています。

パーフェクト"Elixir情報収集" @keithseahus さん

www.slideshare.net

exgettextの話 @k1complete さん

www.slideshare.net

ドキュメントの地域化

gnu gettextとほぼ同じような地域化

ElixirユーザのためのOTP入門 @mururururu さん

shinjuku.ex #10 発表資料

Elixirアプリケーションの設計

  • どう設計するのか、他の言語とは異なる設計になる
    • コード読むしかない
    • よく出てくるパターンを知る
    • 闇雲に読んでもダメ。OTPを勉強するのは大事

OTPとは何か

  • Erlangでシステムを設計するときの原則
  • それに従って実装するためのライブラリ群
  • 木構造の設計をする
    • スーパーバイザ：ワーカの監視などを行う
    • ワーカ：実際に仕事を行う

ビヘイビア

よくあるパターン

  • GenServer
    • クライアント、サーバ
  • Agent
    • 状態を持つ
  • GenEvent
    • イベントハンドリング
  • Task
    • ただ計算を行うなど
  • Supervisior
    • プロセスの監視
  • Application
    • 始点

実際に何が起きているのか、実際にどんな風にできているのか、サンプルアプリ（KVS）を作ってみていくことで学ぶ

samples for shinjuku.ex #10

OTPをよしなに選択して使えるとElixirがかけると言って良いのでは？

Phoenix

使うのに意識することはないが…

まとめ

OTPはパターン

Eilixirを書くということは、スーパーバイザツリーを設計するということ

Ruby on Rails vs Phoenix @ma2ge さん

speakerdeck.com

ここ2、3ヶ月海外でも記事が増えている。流行りだしている

  • Elixir/Phoenixはバックエンド、ミドルウェアだけ？
  • そろそろRails置き換える力があるのでは
    • scaffold
    • eex like erb
    • ドキュメント充実
    • WebSocket
    • Performance Railsアプリのパフォーマンスを改善するにはPhoenixと言いたい

Ruby on Rails

プログラマの幸せと生産性

Phoenix

  • Speedと開発環境を楽しくあろうと作られている
  • Phoenixのスター数はRailsの10分の1
  • 今年中に1.0？

違い

  • ウェブソケット
  • アセットパイプラインがない
    • nodeに頼る
  • SQLite Adapterなかったが開発されている

開発における違い

  • ファイル構造
  • scaffold
    • 同じ
    • named_routeほぼ同じ
  • controller
    • Rails
      • renderを明示的に指定する必要がない
  • View/Template
    • Phoenix
      • templateとViewは独立
        • Viewはプレゼンテーションレイヤのみ
      • form_forが最近実装された
      • ラベル未対応くらい
  • Model
    • Elixir
  • Query
    • ecto
  • Mailer
  • assets
    • brunch.io, gulp, etc..
      • JSはJSに任せる
  • Test
    • Rails
    • Elixir
      • ExUnit
        • アサートがマクロで読みやすい
        • Rspec likeはライブラリもある
  • Ecosystem
    • Rails
      • gems
    • Eilxir
      • hex
        • 数は少ない
        • よく出来ていて作りやすい
        • 他の言語のいいところを吸収していて、可能性がある

Phoenix≒Rails

  • Performance
    • Phoenix > Rails
      • development: 1.7倍
      • production: 3倍
      • 並列: 9倍

まとめ

ミドルウェアだけでなくウェブアプリケーションに使ってもいいのでは

ポテンシャルはある

個人的には、@mururururuさんのOTP入門で、実際にOTPが何をどういう風に抽象化しているのかというところをライブコーディングで学べたのが良かったですね。また機会があれば参加したいです。