Developers Summit 2016に参加した
その時のメモ

大規模Redisサーバ縮小化への戦い – 駒井 祐人さん

AWSのElsasticCacheを64台から8台にしたノウハウ

64台となった経緯

EC2 20台に対してRedis64台稼働していた
当初は8台で運用していたが負荷があがったため、暫定対応として64台に
1redisサーバにつき8DB利用していたが、1redisサーバにつき1DB利用することにした

原因

keys(“*”)コマンドを利用していた
→すべてのkeyを取得するため高負荷となる
　マニュアルにも本番環境では最新の注意を払って利用するように記載されている

デメリット

・月135万円
・冗長化しにくい

redisサーバ縮小化

・当初の設計の1redisサーバにつき8DB利用とする
・DBが分散されているため各サーバでdumpしそのデータをつなぎあわせた
・フッタにチェックサムがあるため注意
・redus-check-dumpfileというコマンドでdump構造に問題ないか確認できる

トラブル

・AWSの最大接続数の上限65500に引っかかった→変更不可能
・EC2サーバ100台 * unicorn 50プロセス * 16DB = 80000接続
→DB数を縮小で対応した

最終的に

・月100万円削減することができた
・マルチAZを利用して、冗長化できた

リアクティブ・アーキテクチャ〜大規模サービス

知らなかった単語を記載

レジリエンス(resilience)

・部分的に障害が発生してもシステム全体に波及せず(自律的に)回復する
・エラーがあっても各コンポーネント内で完結し、他に影響がない
・障害時に処理中のタスクや回復処理を他のコンポーネントに委譲する
・壊れたら管理者や修理できる人を呼ぶ(Let it crash:故障したコンポーネントはその場でcrashして監督者に回復処理を任せる)

弾力性

Scale Out + Scale In のしやすさ

Back-Pressure

Publisherはリクエストされた分だけメッセージを送る
つまり受け取る側が受け取る量を制御する

開発者が押さえておきたいクラウドネイティブ時代のITインフラのトレンド – 桂島 航さん(VMwareエバンジェリスト)

インフラ構築の自動化のためのキーワード

開発者がより早くデプロイ(環境を手にするために)するために必要となっていくもの
・ストレージ仮想化/ハイパーコンバージド
・ネットワーク仮想化/SDN
・コンテナ技術

ネットワーク仮想化/SDN

現状物理スイッチにVLAN設定している構成がほとんど
VMwareではVMware NSXを利用して、仮想スイッチ(つまりハイパーバイザー部分)を
コントロールすることでネットワーク仮想化(ファイヤーウォールやロードバランサーなども)を実現する

構築すると自動的にファイヤーウォールルールが適用され、
ライブマイグレーションした場合、ファイヤーウォールルールも移動するため運用も簡単

ネットワーク仮想化のメリット

・サービス提供までのスピードアップ
・経済性(運用コストの効率化、設備投資のコスト削減)
・セキュリティ
　現状ファイヤーウォールなどで境界を守ることがほとんどであり、侵入されると境界内のサーバ群すべてが影響を受ける
　NSXを利用すると、独立したネットワークの構築や影響があった時に切り離すなどの対応が容易に

コンテナ技術

PHOTON:コンテナ向けに最適化されたLinuxOS(VMwareとの相性がよい)
VMWare Photon Platform
→コンテナを展開するためのインフラ準備中である

デブサミ恒例！コミュニティLT2016

Japan Xamarin User Group

Xamarinとは
クロスプラットフォーム開発環境(MAC/Win/iOS/android)
iOS/androidの一本化はCordovaが強力なライバル

codeseek

コレ読んでみる

日本Seleniumユーザーコミュニティ

selenium使ってみたい