JTF2014行ってきました。
朝起きれなかったので途中からの参加で、かつ夜仕事があったので途中で帰ったわけですが、とても貴重なお話が聞けました！
箇条書きですが自分がメモったことをざっと書きます。

インフラエンジニアのための次世代プロトコル入門

※ 途中から参加

インフラエンジニアのための次世代プロトコル入門 - July TechFesta 2014

HTTP/2.0

  • サーバからpushできる
  • 1つのtcp接続で複数の情報をやりとりできる

QUIC

  • quick udp internet connections
  • udp上に多重化して通信
  • googleが現状のinternetで動くプロトコル実装
  • TCP/TLSは3RTTセッション確立、再接続は1RTT
  • 1RTTでセッション確立、再接続は0RTT(ダイレクトにでデータ送信)
  • QUICはやい
  • packet pacing (流量調整)
  • multi path
  • wifi接続から3G接続のように回線が変わっても、セッションid送ることで0RTTで再接続可能

TLS

  • v1.3策定中
  • ハンドシェイク簡略化を目指す
  • 0.5RTTでも早く

ipv6

  • AzureのUSリージョンでipv4アドレス枯渇発生
  • ipv4-ipv6移行共存技術
  • 新サービスはipv6対応で作ると今度楽できるかも
  • cloudフレアはipv6対応済み。CDN使うのもあり

ハイパフォーマンスブラウザネットワーキング(本)

  • 素晴らしい

まとめ

  • いずれ対応するなら事前に準備したほうがいい
  • HTTP/2.0はデプロイ間近

Dockerのエンタープライズ開発での活用モデル

資料見つけたらはる。

dockerとは

  • google trend 急上昇
  • 軽い。使いやすい
  • 起動が速い。仮想ハードウェア作詞して起動ではなく、ハードウェア、カーネルは共有してるから速い
  • 異なるディストリでもカーネルは共有
  • 物理と同じ速度が出る。virtualboxなどの仮想化は遅い
  • インストール簡単
  • Dockerfileで楽々イメージ作成
  • コマンド一つで起動
  • 後片付けも簡単
  • Docker registry
  • どこでも使える。ポータビリティ高い

仕組み

AUFS
  • 何層にも重ねられるFS
  • readonly-FSの上にwritable-FSを重ねて使用
  • 変更のないファイルはベースで共有する
コンテナ仮想化
  • namespace
  • cgroups
  • PID namespace コンテナ側からは他のPIDに見えない干渉できないが、ホストからはコンテナのPIDは別プロセスIDとして見える
  • Net namespace hostからはvethという仮想NICとして見える
  • cgroup
  • プロセスのリソース制御

事例

CIに利用
  • docker + jenkins + gitlab でCI
  • jenkinsに様々な環境が必要になる
  • virtualbox等で分けたのでは重い
  • dockerで準備すれば軽くできる
評価環境
  • tomcatがまとめて落ちるの困る
  • とりあえずdockerで分けた
  • 開発者の確認終わるまでコンテナ残す必要がある
  • 削除フラグのjob作成していらなくなってから削除
開発環境
  • 複数バージョンの保守が必要
  • 必要なものを全て入れたイメージ作成して利用
  • docker registry利用
  • オーバーヘッド少ないのでいい
  • 環境消すのも楽
複数拠点でのDB利用
  • 海外の複数拠点での同じDB利用
  • 東京-上海間でレジストリーサーバの同期
  • 東京でpush、上海でpull
  • 状況にあったインフラ上で同一環境を作れた

クラウドストレージを自前で構築できる「OpenStack Swift」をPuppetで数百台自動構築して見えた課題と現状のベストプラクティス

openstack swiftとは

  • 世界中でエンプラ用途進む
  • proxyとstorage
  • 故障に備えて複数のレプリカに書き込む(3カ所 or 2カ所書き込みでOK、1カ所だけだとNG返す)
  • ディスク故障時には自動復旧
  • proxyを増やせばスループット上昇
  • storage増やせば容量増える データ3倍保存なので帯域、容量全て食う

利用目的

  • スケールアウトしたい
  • 長期保存したい(非ベンダー依存)
  • 高速、性能重視
  • readのほうが速い
  • 1ファイルへのアクセス集中に強い
  • バックアップ

swift数百台自動構築

  • 数百台(6セット)
  • 監視サーバ等も必要
  • 高水準、少人数
つかったもの
  • kickstart
  • puppet (理由なし)
  • subversion
  • pssh
  • ipmi
  • puppet 自動化、誰でも出来るようにわかりやすく書いた
  • 数百台になったとき、puppetマスターが耐えられない可能性
  • ローカルデプロイ方式でやった
デプロイ手順
  1. ipmiで電源on
  2. kickstart pxeboot
  3. psshでマニュフェスト配布
  4. puppetで一斉に実行
  • 自動試験
  • tempest(openstackの自動試験ツール)を拡張
  • +お手製ツールでテスト(serverspecは評価段階だったのでやめ)
  • tempestでできないこと
  • tempestはapi試験なのでバックグラウンド処理の試験は出来ない
遭遇したトラブル
  • 検証環境のファイルを本番にデプロイ
  • 別の理由で止めておいたプロセスがpuppetで起動しちゃった
  • ファイルでデプロイ出来たが、設定が反映されなかった
  • 本番環境へのプロビジョニング運用はもうやめたい！

インフラプロビジョニングベストプラクティス

  • イミュータブル
  • blue-green deployment
  • packer ビルドツール
  • 複数クラウド仮想環境に対応
  • 開発環境と本番環境の差異を吸収できる
  • クラウド環境の移行も楽
  • dockerもいい
  • 基本はpackerを使う(dockerfileは使わない)
  • dockerはあくまでプラットフォーム
  • dockerはまだ課題あり
  • DB、ログはどうする？

まとめ

  • 自動構築は出来たけど、運用でトラブった。
  • 本番環境に手を加えるべきじゃない。
  • ネットワークの冗長度は落とさないほうがいい
  • RAIDはいらない

世界で最も高機能なオープンソース・ハイブリッドクラウド自動化システム「openQRM」で実現するOpenStack/AWS統合管理

  • セルフサービス化と課金システム
  • 複数クラウド環境での双方向インテグレーション
  • openQRMがあればvCenterいらない？
  • KVMの管理も可能
  • APIもある

ここで途中帰宅。。。

楽しかった

  • これからopenstackやろうと思えた。
  • GlusterFSでいいじゃん派だったけど、swiftも見てみようと思った。
  • dockerはやっぱり楽しそう。
  • お昼美味しかった。
  • 最後まで見たかった。