#ichigayageek 愛の貧乏大作戦！ケチケチビッグデータ節約術に参加してきました #メモ #レポート

2015-06-17 に開催された愛の貧乏大作戦！ケチケチビッグデータ節約術（市ヶ谷Geek★Night #2）に参加してきました。

振る舞っていただいた叙々苑焼肉弁当が美味しかったですー完

...

......

......... としてしまいそうなところではありますが、わたしがとってきたメモを例によって公開しておこうと思います。

先日、話題になっていた勉強会のドタキャン・無断欠席回避問題ですが、叙々苑の焼肉弁当、かなり効果があったのではないでしょうかｗ

さて余談はさておき、勉強会そのものは「ケチケチ」という枕詞とは裏腹に、「リッチ」な内容*1でした。
次回もすでに開催する予定があるようなので、都合が合えば、自分も参加させていただこうといただこうと思います。

では、ここからメモです。

まず、そもそも市ヶ谷 Geek Night とは？

業種関係なく、ひとつのテーマについてその分野の先駆者にきてもらって話をしてもらおうと思って開催している、勉強会とのことでした。
ハッシュタグは #ichigayageek

主催者の株式会社オプトさんより

Web 広告の代理店会社だが、エンジニア比率が小さいのが悩みの種。
なのでエンジニア採用を活性化している。
- オプトテクノロジースをローンチ計画中。
R&D のデータサイエンスラボをはじめていたりもする。
- DeepAnalytics （ググれば出てくるよ）というサイトを運営。
- こちらでも同志を募集中。

膨大な数のグラフを扱うGraphillionの紹介と活用事例について

概要

これまでに多くのグラフライブラリが開発されておりますが，それらはひとつのグラフを処理するために設計されています．最適化問題などでは，複雑な制約条件を満たす指数的な数のサブグラフを扱う必要に迫られますが，それらを効率的に扱うことはできませんでした．本発表では，Graphillionという膨大な数のグラフを効率的に扱うPythonモジュールを紹介します．Graphilionは，特に中規模サイズのグラフを綿密に調べきるような用途に向いています．パズルソルバや電力網最適化などのケーススタディを通し，最適化やシステム検証などの複雑な問題を簡単に解決する様子をご覧いただきます．商用サービスではなく学術成果であるため，完成度・サポート等についてはご配慮いただければと思います．
NTT未来ねっと研究所井上武（いのうえたける）
github：https://github.com/takemaru

グラフ列挙アルゴリズムで書籍を出してます。
Graphililion
- Python モジュール
  - 8 割くらいは C と C++
- x-illion of graphs
- 膨大な数のグラフを効率的に扱うアルゴリズムを提供する
- 最適化や検証、統計などグラフの問題を解決する
- イテレータにより必要なグラフのみ取得
みんなで数えてみよう
- 「数え上げおねえさん」の話を今日はする
  - 『フカシギの数え方』おねえさんといっしょ！みんなで数えてみよう！ - YouTube
なぜグラフなのか？
- 多くの問題に用いられる数理モデル
- 様々なアルゴリズムに共通する統一的な抽象化
- 理解しやすさとバランスがよい
なぜグラフ「集合」なのか？
- あるグラフの様々な部分グラフとして自然に登場する
  - 地図上の可能な経路や電力網の配電方法など
Demo
- Graphillion: 数え上げおねえさんを救え / Don't count naively - YouTube
Graphillion の外観
利用事例
- アカデミックなものなので、これを使ってマネタイズしているという事例は知らないとのこと
- 熱として失われる電力
- 最適な配電経路の探索
- Ekillion
  - 電車大好きな人がつくった
  - 目的地に一番遠回りするにはどうしたらどうしたらいいのか？
  - 目的地へ行くのにどれだけ違う経路があるのか？
- パズルソルバー
  - ナンバーリンクの問題例とその解答
- ネットワーク信頼性の評価
  - 北大 2014 の入試問題は Graphilion を使えと言ってるとしか思えない！
- Graph Golf
  - Graph Algorithm のコンペ is-candar.org
  - 締め切りは今年の 10 月

財布の紐を限界まで締める！AWSスポットインスタンスの真髄

概要

大局的にみればAWSの費用は決して高くはありませんが、それでも、より安価にできないか常に考察し続けることはインフラエンジニアとしての責務であり、また上層部から降ってくる無茶ぶりでもあります。AWSには様々な選択肢が用意されており、EC2のスポットインスタンスもその１つです。このスポットの、あまり知られていないであろう仕組みを使い、安全かつ大幅にコスト削減する方法を紹介します。
株式会社ドリコム外道父（げどうちち）
twitter : @GedowFather
blog : http://blog.father.gedow.net/

スポットインスタンスそのものが節約術ではある。
資料は明日辺り up するつもり
まだオンデマンドでお布施してるの？そらウハウハで売上高を公開しちゃいますわ？！
基本と目的
- スポットとは?
  - ちょっと安くて
  - 起動が遅い
  - 強制削除される可能性
- 安い理由は入札式
  - 余っているリソースを使ってもらうため
  - 需要と供給により価格変動
- 費用の比較
  - オンデマンドが 100 としてスポットは最小 14 最大 1,000
  - スポットの wkwk 感
- 価格の変動
  - 予測は不可能
- 起動時間が少し遅い
  - スポットはまず入札があるから
- 強制削除
  - 入札価格>=
- リソースは全く同じ
  - オンデマンドのインスタンスもスポットインスタンも元となるインスタンスのスペックは全く同じ
- 変動価格の最大値
  - 変動価格は最大 10 倍まで決まってる
    - 10 倍で入札すれば落ちないっていう仮定？！
      - でも落ちるんですな、これが、と。
        
        需要と供給で成り立っているため、需要が急増したときには入札や変動価格の高低にかかわらず強制 Terminate されることがある
  - 入札価格も 10 倍までということ
    - 2015-04 からルールが変わった (全体的にはルール変わってよかったね)
- 強制 Terminate をインスタンス自身が知ることができる
  - URL がある (資料)
    - 普段は 404 Not Found
    - 詳細資料！
- 通用のインスタンス破棄前に任意の処理を行う
  - AutoSlace における起動完了前や削除実行前に任意病を待機し、任意の処理をおこなうための Lifecycle-hook を使う
- 入札数の制限
で、どうやって攻めのアーキテクチャを組むのか？
- 入札価格をオンデマンドの 10 倍にすることで強制 Terminate を避ける
- スポットの仕様変更や機能追加に追随し続ける
- 制限値を上げる申請をする
  - 特に AutoScalingGroup
AutoScalingGroup
- どうやって組んだか、は資料を見たほうが早い
- 細かく分けた理由
  - 変動価格がインスタンスタイプ/AZ単位のため
  - 複数のインスタンスタイプ→高騰による強制 Terminate を避けるため
- オンデマンドも併用する理由
  - スポットが不調なときのため
  - 急激なスケールアウトが必要だった時のため (起動が遅い)
  - 監視用インスタンスはホスト名や IP アドレスを固定できないからそこは確保しておきたい
- スポットメインのスケール条件
  - 平時はスポットだけが増設され、有事オンデマンドも増設。
  - 落ち着けばオンデマンドから削減される
- 高騰したスポットは破棄する
  - グループ単位で価格を監視。高騰と判断したら、インスタンスを破棄してグループの稼働を停止する。
  - ヒット・アンド・アウェイ
- 高騰と平常の判断条件
  - 直近 1 時間の平均を比較値として利用
  - 1 時間に数十ある履歴の価格と割り当て時間から計算する
  - わずか数分の突発高騰でインスタンス破棄は防ぐ
- 高騰リスクの低減
  - 1 グループ価格高騰で死んでも、残るグループの負荷は 3/4 になるだけという考え方
通常停止対策
- LifecycleHook で安全にシャットダウン
- その通知と問題点
  - 通知はインスタンスが直接受けるのではなく SNS/SQS として受け取る
  - メッセージ内に Complete を送るためのトークンがある
  - SNS は余剰サーバが必要
  - SQS だとインスタンス自身でとれるが、、、
- LifecycleHook の通知を受け取るための仕組みを実装した
  - 10sec ごとに全インスタンスでキューをチェック
  - さらにインスタンス自身のタグをチェックし、タグがあれば Complete 処理
- Liux の init システム管理では挙動が不確か
  - LifecycleHook が確実な手段だし便利なのでおすすめ
強制 Terminate に備える
- URL
- Bash デーモン
- 5sec ごとに関し
- 唯一の弱点
  - 一回一回の処理が短い http は問題ない
  - 1つの処理に数分数十分以上の持続接続が必要な場合はジョブの処理終了に間に合わずに落とされてしまう可能性がある
オンデマンドとの費用比較
- 最小台数の場合 34% の削減効果
- 大規模台数の場合 81% の削減効果
- 1時間平均の価格変動グラフ (独自作成)
  - ほぼオンデマンドの 20-25% をキープ
- インスタンスタイプの選択
  - 希望は 2xlarge だったが
  - 最初に採用したのは c3/c4.xlarge
  - 今は c3/m3.xlarge に避難 (c4 がご乱心 & m3 安定)
- オンデマンドいる？
  - おもいのほかスポットで稼働できる、が
  - そこまでスポットは信用すべきものでもない
    - オンデマンドが最終防衛ライン
その他の工夫
- 時間が足りないっす
- 続きは Web で！
オチ：でもスポットはやめたほうがいいぜ、なぜならオレのコストがあがっちまうからな！

Gyazoを支える技術〜3億行の分散データベース、100TB/月のトラフィックの激安運用法

概要

Gyazoは、現在、3億行300GBのデータベース、90TBのストレージ、100TB/月のトラフィックを抱えますが、これを素直にAWS等で運用すると破産してしまいます。また、ユーザーが北米40%、ヨーロッパ40%、アジア20%と分散していますので、分散処理も重要になります。人的なオペレーションコストと、サーバーコストを両方をそれぞれ抑える運用ノウハウを公開します。キーワード：大陸間分散レプリケーション、CDNとキャッシュ、クラウドと専用サーバーの使い分け、オートスケール、Docker／Chefなど
Nota Inc. 洛西一周（らくさいいっしゅう）
twitter @rakusai
facebook https://facebook.com/rakusai
github:https://github.com/rakusai

Gyazo とは？
- 増井さん
  - 富豪的プログラミングを提唱
    - コンピュータは酷使してなんぼ
- カーリル
  - Librahack 事件とか
- スクリーンショットをとったそばから Cloud に、とか
  - Gyazo gif とか
- ネット上で強力なユーザ文化を形成し、動詞化された
  - Gyazo
  - Gyazod
  - Gyazo it
    みたいなのを Twitter で散見されるように
- グローバルなシェアも獲得するように
  - 北米、欧、 JP
  - 動画、画像は国境を超える
- 月間ユニークユーザ 1,000 万人超えた
けちけちインフラの話
- 富豪的プログラミングを提唱しているので、インフラはどんどん肥大化する
- 構成図
  - Google Compute Engine を使用している
    - App GIF グラフレンダリング
    - DB
    - Storage
    - Upload
- けちけちしすぐると失敗する
  - ログがたまりすぎて容量不足
  - メモリ不足に気づかない
  - 激安 CDN で遅くなる
  - ひ弱なクラウドインスタンスは CPU 、 IO が不安定 etc...
- けちけちしすぎない設計術
  - 人の負荷を最小限にする
    - サーバが落ちると数人の数日は無駄になる
      - 結局、人のコストが一番高い
        
        インフラエンジニアだけでなく、サポート、経営すべての負荷になる
- Gyazo の抱えてきた問題
  - DB
    - 大陸間 Replication
  - Storage
    - 米国にストレージをおくとアップも配信も遅い
  - App
    - DDoS 攻撃、一時的なトラフィック増加
  - その他
    - ログの視覚化
- オンプレから AWS に乗り換えた (4年くらい前)
  - サーバを追加、入れ替えするたびに、中の人に連絡して値段交渉するのが面倒くさくなった
  - DDoS 攻撃時に NW 全体が遮断される
  - 初期設定時に LAN の設定を間違える
    - オペレーションの質が低い
- fluentd + kibana
  - 正常系と Error を監視
- それでもまだまだインフラに時間をとられれすぎ
  - 大陸間のファイアウォール設定めんどくさい
  - etc....
- で Google に乗り換えた
  - 理由
    - インスタンスが落ちない (実際には落ちるけれども Live migration で断は 10sec)
    - インスタンス起動が速い
    - 全世界で地域間をローカル IP でアクセスできてしまう
    - ストレージが速い (エッジキャッシュ)
    - SSH キーを管理しなくていい
    - リザーブドインスタンスがない
    - オートスケールの待ちがない
- MySQL から MongoDB に乗り換えた理由
  - Slave 停止時に Master を停止しないといけない
  - Column 追加のコスト
  - 大陸間 Replication はほぼ無理
  - Mongoid は便利
  - US に Primary 、各国に Secondary
- でも、一部でオンプレを使ってるのは？
  - ネットワークトレフィック課金が高すぎる
    - Cloud では $0.1/GB = $100/TB
    - リアルタイムエッジキャッシュ
      - アップロードした地域サーバにキャッシュを残し、同一ユーザのアクセスはそこから配信
      - けちけちとさらに、キャッシュの有効活用
        
        UDP ブロードキャスト
- 監視の失敗 - Gyazo は眠らない
  - ピークタイムがない
  - もろもろの問題
  - 今は Google Cloud Monitoring
  - 自動で電話
    - hubot + Twilio で寝ている社長に電話
  - オフィスの電気が赤くなる
    - hue を利用
- 弔い方
  乗り換えを繰り返しているので、毎回コードを弔っている
  - ホワイトボードに書く
まとめ
- インフラ担当者の仕事を減らす
  - もっと楽しいプロジェクトが増やせる
  - フロント・サイドの仕事に集中できる
GyaPC Asia::Tokyo 2015 やるよ