heki1224の適当な日記

技術知識を忘れないように書き留めておくブログ

BPStudy #81 に行ってきました。

ご無沙汰しています。

DockerやCoreOSのお話が聞けるということで
久しぶりにBPStudy#81 - connpass
に行ってきました。

5月30日に開催されたもので、あれから1ヶ月以上も経ってしまって
全くタイムリーではないですが、メモ残しておきます。

BPStudy 

HHVM 入門
19:21 - 19:44

〜〜〜途中から〜〜〜
Tool
 - fastcgi
 最新版から設定シェルが付いた
 →便利だから使いましょう

WebApplication
 - first step
 動いてるかどうか分からないから
 phpinfoを確認する
 
 - はまりどころ
 ・設定ファイルが.iniファイルだけ
 php include_pathの設定が効かないため
 実行時に設定する必要がある
 ・実行時
 <?hh echo でHTMLに記載したものはまだ動かない

Performance
・bench.php
 100万回ループするのを2回呼ぶ
  結果:hhvmの方が10倍くらい速い

・wordpress ab
 hhvmの方が2〜3倍くらい速い
 
HHVM Extensions
・HHVMの拡張機能でありC++の既存資産を生かすことが可能
  HNIと呼ばれるHackの記法を使う
  ・必要ファイル
  ・・・本家そのままじゃ動かない

PHP2HHVM
・PHPファイルをそのまま使う
  HHVMのみ利用する(おすすめ)
・PHPファイルをHackに移行
  nullを許容する場合のみ明示的に?を指定
  積極的にCollectionを利用する(速度とメモリ使用量削減)
  hh_clientにてチェックを行う

まとめ
・Hackは無理に導入する必要はない
  今はまだ・・・。
・HHVMは積極的に採用しよう
  Facebookの実績
  3年後HHVMがデファクト・スタンダード
  nginxの出始めの頃
BPStudy

CoreOS入門
19:48 - 20:40

自己紹介

宣伝
Docker入門の薄い本書きました

CoreOSとは
・分散システムを前提に設計されたディストリビューション
・Googleなどを参考に

オフィスの様子
・ガレージでやってる

CoreOSの特徴
・クラスタ+コンテナ
・コア
・バージョン
 CoreOS諸般からの日数で付いてるらしい

セキュリティ、一貫性、信頼性
・sshのみでログイン可能
・パッケージマネージャが存在しない
・root partitionが書き込み不可能
 ・/etcは一部可能
 ・ユーザーデータは外部ストレージ

安全なアップデート
・update_engineを提供
 alpha,betaの2チャンネル
・アップデートはroot乗せ換え
・update元イメージは署名入りで検証

Docker
・アプリケーションは基本Docker上で起動
・ポータビリティの確保
・コンテナ間連携にetcdを使う

クラスタ
・etcdによって実現
 耐障害性
・アルゴリズムにRaftを採用
・ユーザーデータを保持可能
 設定などを同期

分散システム
・fleet = etcd + systemd + job scheduling
・複数ホストへサービスを配備
・耐障害性
 障害を検知し、別ホストへサービスをふりかえる
・ログはsystemd-journaldと連携

構成要素
・coreos-cloudinit
・etcd
・fleet
・locksmith
ライブラリ依存を最小限に抑えるためgoで書かれている

CoreOS-CloudInit
書き込み不可能なCoreOSを初期化し、カスタマイズする仕組み
・クラウド環境での一括初期化
 cloud-config.ymlサポート
・ユーザーによるカスタマイズ
 サービスの追加など(ロギング系)
・外部デバイスからの読み込み
 config-driveのサポート
 OpenStack,LibVirt

主な設定可能項目
・etcdの設定
・serviceの自動起動
・ユーザー追加
・個別設定ファイル作成

etcd
クラスタの基盤となる耐障害性のある分散KVS
・HTTP API(JSON)での操作
 CASのサポート
 Waitによる変更監視サポート
・高速に動作
・SSLによる認証
・Raftプロトコル
・Cluster Discoveryのサポート

HTTP API
SET
$ etcdctl --debug set /message "Hello World"
GET
$ etcdctl --debug get /message

Raft
ノード間のコンセンサスをとるアルゴリズム
民主的(Vote)で合理的なアルゴリズム
・リーダーの選出
・ログのレプリケーション
・設定の同期
・実用的、合理的
※動画あるので探してみる

etcdの現状
・Raftは大きなクラスタ組むのに適してない
 適切なサイズは5-9
 Stanby Mode
・リーダーのハートビートがことごとくtimeout
 デフォルトで50ms
 peer-election-timeoutのと油性
 heartbeat-intervalの調整
・Discoveryで失敗した場合の復旧

Stanby Mode
Etcd 0.4からサポート
・クラスタサイズの設定
 最大アクティブノード数を設定(9)
 あふれたノードはStanbyModeへ
・Stanbyノード
 アクセスはすべてリーダノードへリダイレクト
 Stanbyでも一定時間毎にリーダと設定を同期(5秒)
・Follwerへ昇格
 アクティブノードに空きが出来ると昇格する
 昇格時は再度同期

Fleet
SytemdとEtcdを利用した分散システムツール
・コンテナをクラスタにデプロイ
 特定のコンテナを同じマシンにデプロイ
 Metadaにマッチングしたマシンにデプロイ
・同マシンにデプロイされないよう禁止
・コンテナの障害を検出し、他のマシンにデプロイ

EngineとAgentに分かれる
・Egine
 ジョブスケジューラ
 AgentへJobをお願い
・Agent
 Jobの実行判断
 実際のJobを実行

Fleet with Systemd
FleetはSystemdのUnitを対象マシンへ配布
・ServiceTypeのUnitとして利用
・障害を検知するとUnitファイル毎削除
 motd

Fleet拡張
[X-Fleet]セクションによる独自拡張
・X-ConditionMachineID
ほか

UnitFile例

Fleetの現状
・ハートビートタイムアウト問題
・ジョブスケジュールに優先度なし問題
・ジョブ登録のセキュリティ
 誰でもデプロイできる
 証明書はこれから・・・

locksmith
クラスタ上のマシンのRebootを管理する
・自動更新で一度に全てのマシン落ちないようにする
・update_engineのイベントを監視
・semaphore形式でロックをかける
・よくpanicを起こしている

DEMO

今後の課題
・安定性
・クラスタサイズ
・fleetなどのセキュリティ
 unitに証明書がない
・高レベルのオーケストレーション
 コンテナ間をより簡単に連携

運用にあたっての課題
・クラスタ設計
 スペック、数、ストレージ容量
 クラスタ内におくもの
 クラスタ外におくもの
・オーケストレーション
 ツールどうするか問題
・システム監視
 メトリクス収集
 ログ収集
 監視アラート

Docker前提の設計
・外部ホスト前提
 confd
・永続化データの保存先
 外部ストレージ
・ディスク使用帯域の制限
 blkio
 btrfs quotaぐらい?