元RX-7乗りの適当な日々 このページをアンテナに追加 RSSフィード Twitter

RX-7(FD3S)WRX STI関連のキーワードで検索されて来られた方へ。
右サイドのカテゴリ『』をクリックすると関連する項目だけが表示されます。
日々の写真は『Flickr』で公開しています。

2014/02/14

デブサミ2014「グリーを支えるデータ分析基盤の過去と現在」講演メモ #devsumi


どこもそれなりに苦労・工夫しているよなぁと、興味深く聞かせていただきました。


「グリーを支えるデータ分析基盤の過去と現在」

  • 橋本 泰一 氏
  • グリー
  • 10年ほど東工大で助手・特任准教授した後、2012年にグリーにジョイン

過去の話(2011年)

  • Webサーバからログをrsyncでストレージへ
  • バッチ処理で集計してDBへ(MySQL)
  • ストレージもDBもハードウェアはSolaris Sun Fire X4540

だんだん困ってきた

  • データがほしい人が増えてきた
    • サービスや人が増えてきた
  • データ提供が正直しんどくなってきた

今の話: コンセプト

  • Accessability
    • だれでも自由に
  • Scalability
    • どれだけ貯めこんでも

グリーのデータ分析基盤

  • ゲーム
    • Treasure Data ベース
      • ゲームへのアクセスログ
  • GREE Platform
    • Hadoopベース
      • ゲームからAPIへのログ
      • ユーザ情報

ゲームのデータ分析基盤

  • Treasure Dataを採用
    • Hadoopクラスタの構築が不要ですぐに利用可能
    • ログのコレクトからストアまでワンストップで提供
    • スキーマレスで自由度の高いログフォーマット
    • データ・ウェアハウスの運用コスト低減
    • BIツールとの容易なインテグレーション

基本的な構成

タイトルごとに、、、

Web Server -> LOg Aggeregator Server (2台) -> Treasure Data


規模

  • 約20ゲームタイトル
  • Webサーバ2000台
  • log agg 40台以上
  • 送信データ量 1TB/月

データを使って何をやるか

  • ログデータをゲーム改善のアクションにつなげる
    • アクセス遷移分析
    • Webサイト分析では一般的な手法をソーシャルゲームに導入
  • ジョブ管理をしっかりする
    • 集計状況をモニタリングするジョブ管理ツール

アクセス遷移分析

  • ページ遷移
  • 離脱
  • クリック

離脱分析

  • ページ遷移+ユーザセグメント => 離脱原因を探る

クリック分析

  • データソースは、アクセス遷移分析結果
  • Chrome Extensionを利用して、実際の画面にオーバレイ表示
  • クリックログをJavaScriptでサーバ送信
  • お知らせやランキングの効果などで活用

ジョブ管理ツール

データを社内に解放したところ、非効率なジョブが大量に投げ込まれる。

  • ジョブのモニタリングと管理が重要
    • Treasure DataのAPIを使ってモニタリング
    • ジョブを可視化
    • ジョブ送信元の特定
      • クエリ実行の際に送信者を自動付与
    • スロークエリの可視化と特定

GREE Platformのデータ分析基盤

Hadoopをベースにして自作している。

  • source
    • Webサーバ - Fluentd
    • MySQL - db-express
    • Storage
  • Analysis Data Hub
    • HDFS
    • MapReduce
    • Hive
    • Presto
    • Macaron
      • 自社製
  • HBase

主な構成

  • JDK7 + CDH4 + Apache Hive (v0.12+α)
    • Hive Server2
    • 追加パッチ
      • Hive 1511, etc...
    • 独自拡張
      • 社内認証システムとの連携
      • auto-load extra UDFs

規模

  • 5000ジョブ/日
  • 60TB
    • 数ヶ月分のデータ、圧縮した状態、レプリカは除く
  • 今は120〜130ユーザ
    • ほとんど非エンジニア

データへのアクセス方法

  • 直接アクセス
    • SQuirreLSQL
    • JDBC, ODBC接続
  • グラフ化
    • Macaron
      • 自社製
  • その他
    • Shell, Python, R, PHP, …
    • thanks to Thrift

Macaron

  • データをグラフ化してくれるツール
  • RDB/Hiveに対応
  • 過去に投げたクエリはキャッシュする機能
  • 出力: 画像、HTML

Ruby Scripting in Hive Query Language


データのインポート

  • ログデータのインポート
    • ハイブリッド: bulk copy + streaming log events
    • Fluentd & WebHDFS (まだ不安定)
  • MySQLからのインポート: db-express
    • Sqoopのラッパー
    • Cooperation w/ in-house DSN catalog
    • Parallel import Shareded Databases / Tables
  • 手動インポート
    • ブラウザからアップロード

近い未来の話:

  • コンセプト
    • Speedy
    • Intelligently
  • PrestoとSpark(YARN)に注目

YARN

  • リソース管理をやりやすくする仕組み

Presto

  • OSSな分散SQLエンジン
    • Facebookが開発
    • HIveに置き換わるもので、Hiveより速い

Spark

  • データ処理フレームワーク
    • 機械学習の利用に最適化されていて、速いのが特徴

2014/02/13

デブサミ2014「さくらのクラウド開発と運用、裏話的な何か」講演メモ #devsumi


クラウドサービスがどのように作られることになったか、とかどのように開発されたかの裏話。生々しい話も所々出てきて面白かったです。

運用の部分、時間がなくなってしまって割愛されていたのですが、そっちも是非聞きたかったです。


「さくらのクラウド開発と運用、裏話的な何か」

  • 鷲北 賢 氏
    • @ken_washikita
  • さくらインターネット研究所
    • 所長
    • さくらのクラウド開発チームリーダー兼務

「中間管理職PMの立場でお話します。」


さくらインターネット

データセンターを中心とした事業。

  • ハウジング
  • レンタルサーバ
  • 専用サーバ
  • VPS
  • クラウド(IaaS)

2009/05

  • 「さくらはVPSをやらない」と高らかに宣言(したように見えた)
    • 社長が当時の@ITにて
  • 現実として、社内に仮想化サービスを検討するプロジェクトは皆無
  • 社長の記事のおかげで、「やっちゃいけないんだな…」という空気が醸成

2009/07

  • 研究所設立
  • 面白いことは何でもやるをモットー
  • 当初は、IPv6実装とか硬めのテーマが主流
  • 仮想化技術をやらないのは個人的にやばいと思っていたので、自ら研究テーマに選んだ。

2009年頃のクラウド事情

  • EC2がすごいともっぱらの評判
  • 個人で試すことが多かった
  • 実験で立てたサーバを消し忘れて「クラウド破産」する例も
  • 当時、アメリカではEC2を使ったサービスは続々リリースされていたが、国内では事例が少なかった
    • 勉強会では、法律も違うしデータを差し押さえられるのでは、という議論もあった
  • ただサーバを作ったり消したりするだけでも楽しい、という雰囲気

仮想化されたサーバサービスはすごい

  • 時間単位でサーバが借りられる、これだけで破壊的
  • どうやってサービスを実装しているか想像するだけでも楽しい恐ろしい
    • 例えば、1日で1000台つくって1時間で解約、というスケールに対応する必要がある
    • 途方もないリソースプールをどう用意するのか
  • 真面目に取り組まないと到底作れないと焦った

研究所の方針

  • Linux KVMを採用
  • ネットワーク設計は独自に設計
    • 当時のCloudStack, OpenStackはまったくスケールしなかった
  • ストレージ仮想化は、、、決め手に欠くまま2年が過ぎた

2010/01

  • 社長が突然「クラウドやろう」と言い出した
  • 社長個人サイトがアクセス津波でえらいことになってた
    • 社長はEC2を使って対処。悔しかったw

さくらインターネットの怖いところ

  • 日曜プログラミングの延長で、社長がプロトタイプを作る
  • 動くものを使ってデモ。エンジニアは逃げ場がなくなるw

VPSプロジェクト発足

  • 社長のプロトタイプを受けて開発部がプロジェクトを担当
  • ハードウェアの選定
  • コントロールパネルと課金系の構築
  • 研究所の役割
    • KVMの性能評価等はレポート化していた
    • スーパーバイザーとしてMTGに参加

2010/09、VPSリリース

  • 6ヶ月でサービスにもっていった開発部すげぇ、と思った
  • リリース後もすごいスピードでユーザが増えて大変なことになってた
  • 現在は、5万を超え、6万に迫るVM数(!)

2011/03/02

  • AWS東京リージョン開設
  • 即座に社長の呼出がかかった
  • 研究所と新規事業室でクラウドを作ることに
    • 企画と開発はVPSにかかりっきり
    • プログラマもPMも全然足りない
  • プロジェクト発足キックオフの翌日が大地震…

最初のMTG

  • プロジェクト・ミッションの定義
  • VPSの問題点
  • 提案
    • ネットワーク中心にサービスを考え直す
    • Demo or Dieをモットーとし、まず制作に取りかかる

構成

  • 物理はネットワークを中心に設計
  • APIが中心
    • 全リソースをコントロール)

開発の流れ

  • ネットワークの基本設計は出来上がっていた
  • ホストサーバはVPS運用実績を元に再設計
  • ストレージはゼロから検討
  • APIとDBはプロトタイプをベースに再設計
  • 課金システム
    • 時間課金を実装するのは初めて
    • 既存の課金システムと切り離して実装、既存とは売上データだけをやりとり
  • UI(コントロールパネル)は自由度MAXで
    • 当時、20歳くらいの若者が実装

開発スケジュール(2011)

  • 4月に調査・検討を開始
  • 9月にオープンβ開始
    • 大阪で30台規模
  • 11月に石狩IDCで構築開始

最初の段階は120台のサーバを準備。夏までに検証した上で発注。


リリース直前

  • クラウドのリリースが2011/11/15(石狩IDCの開所日と同時)リリースに決定
  • 石狩IDCの竣工、引き渡しが11/11...
  • 実際は、10/31から作業(納品・開梱)
  • 幸いトラブルはなく、オンスケでリリースできた

11/15サービススタート

  • 当初予定の2倍のスピードでインスタンス増加
  • 2ヶ月でストレージが音をあげはじめた
    • 前倒しで機材追加するも根本解決にならず
  • ストレージシステムの作り直し
    • 新規受付停止
    • 課金も停止

その後

2012年には、ストレージも安定運用・回復。

その後も、リリースを続け、2013年には第2ゾーンの提供開始。サービス拡充中。


インスタンス増減の状況

  • 多くはインスタンスを作ってから、すぐに消される、の繰り返し
    • 定着率は12〜13%
    • 純増を続けている

運用の話(のところで、あと5分)

(以降、色々割愛されていたので、メモを取れたところだけ。)


仮想リソースの障害

  • 従来の物理サーバによるサービスでは、24/365体制で多くのコストが必要だった
  • 仮想リソースでは、設定・ソフトの問題がほとんどなので、設定変更で対応できる
  • 再起動・再割当の時間が非常に短い

障害対策

  • 1点の物理障害が、クラウドのどこの障害につながるかが非常にわかりづらい
  • 極力シングルポイントをなくす
    • 障害が発生しても、自動的に復旧する構成に
    • ただちに影響が出ない設計
  • すべてのコンポーネントを監視する

デブサミ2014「社内システムの構造と設計、実装のはなし」講演メモ #devsumi


失礼ながら、モリス節炸裂しまくりで面白かった。話上手だなぁ。


「社内システムの構造と設計、実装のはなし」

  • 田籠 聡 氏
    • @tagomoris
  • LINE(株)
    • 開発支援室

LINE

「LINEというサービス、みなさんご存じない方もいらっしゃるとは思いますが(ry」


DevOps, by Ops, for Ops

今日言いたいことは、、、

  • 社内システムほど他システムとの連携を考えよう
  • 社内システムではJSON APIを使おう
  • 必要なものを作ろう

これから1つずつ説明します。


Webサービス今昔

  • Web2.0: マッシュアップ全盛期
  • OAuth流行、支配的に
  • WebAPIの制限
    • GoogleMapsのJS APIの制限等

Open Web API

  • トラフィック、レスポンスタイムが課題
    • ニコ動も最初はコンテンツストレージにyoutube使ってた
    • 太平洋横断してTTLが
  • コストは誰が払う?
  • 互換性
    • API仕様が変わると、追従が大変

社内システム: Closed Web

  • 機能>性能
    • 性能が問題になることはほとんどない
    • せいぜい数百〜数千人
  • Long Life Cycle
    • 社内システムのライフサイクルは長い
    • ライブドアでは、2000〜2001年頃作られたホスト管理システムが今でも生き残っている(!)(訂正) 2010年には撲滅されたそうです。聞き間違えました。すみません。
  • Target User: 自分
    • ドッグフードを食べることを意識

社内システムについては、まず機能面に注力すべき。


問題

  • 情報と権限が分断
    • 誰が何を見れるか、どういう情報を持っているかが、わかりにくくなりやすい
  • 情報と機能の冗長化
    • 社員名簿があらゆるところにあるとか、同期が一日遅れ・・・
    • 自社システムでパスワードを複数持ってる・・・
  • UXの欠如
  • 自動化の障壁
    • スクレイピングできるならまだしも、見ても問題ないはずなのに認証が必要みたいなケースも
  • 全部入り: アップデート不可能
    • てんこ盛りだと、どうしてもアップデートが遅れる、億劫になる

社内システム連携

  • DBを直接参照
    • 密結合なので、負の塊を増やす元になる
  • SOAP
    • まだあるみたいだけど、なかったものにしたいですねぇw
  • CORBA
    • ありましたねぇw
  • SOA!
    • ソフトウェア高い、使いにくい、認証どうすんだとか、色々手間が
  • RPC Protocol
    • Protocol Buffer, Thrift, XML-RPC, MessagePack-RPC, ...

社内システム連携: Make it simple!

  • 権限の分断を最小限に
  • 情報には複数の参照方法を
    • ブラウザで見る、APIでやりとりするとか
    • UIを作るときは、できれば自身のAPIを呼び出すように作っておくことが望ましい
  • モジュール化
    • 単機能システムを連携させる
    • アップデートが容易な状態を保つ

ということで

社内システムほど他システムとの連携を考えよう。

機能をAPIとして公開しよう。

  • APIの互換性さえ保持しておけばバックエンドはいくらでもリプレースできる
    • プロトコル、データ構造、意味の一貫性、クライアント要件の不変性/普遍性

Protocol of Closed Web API

  • Thrift, Protocol Buffer
    • IDL: DSL的なもの
  • FTP, RSH, SSH, …
  • HTTP
    • SOAP, XML-RPC, ...
    • JSON

なぜJSONか

  • 長期運用が前提
    • ドキュメントは風化する
    • 一番わかりやすいのは、自分の目で見て確認できること
    • YAMLとかXMLとか色々あるけど、個人的にはJSONがみやすい
  • 長期運用=きちんろアップデートするということ
    • データ内容の把握
    • 人間が目で見てわかりやすいフォーマットが大事
  • テストの容易さ
    • Curl is great.

百聞は一見にしかず

  • 1 time curl >>> 100pages docs
  • easy to try >>> performance
  • loosely coupled >>> script control

より祖結合で、解釈の自由があるフォーマットは、かっちり決まったプロトコルより、社内システムにおいては重要。


社内システム

  • 動くことが大事
    • 納期より、まずは動くこと
  • 「こんなこともあろうかと」は要らない
    • 社内システムなので、必要なものだけでいい。今欲しい必要なものしか作らない。

優先度ハック

  • 自分たちのシステムなので、優先度が決められる
  • 機能・実装を刻むことができる
  • 修正単位を最小化する

逆優先度ハック

  • 刻まれた細かい機能追加タスク
    • 1つ1つのタスクが刻まれることで優先度をつけやすくなる
  • 今いらないなら、あとでやればいい
    • 細かい問題に落としておけば、いつでもできるでしょー
  • (将来の)要件定義は難しい
    • だから後回し
    • 社内システムで自分たちが作るからこそ、できること

実装は必要なところから!


開発アーキテクチャ

  • アーキテクチャの割り切りが開発と運用を加速させる
  • 疎結合に割り切ったアーキテクチャが大事
  • 開発・運用の前提が、アーキテクチャをシンプルにする。
  • ビジネスへのインパクト
    • 社内システムほど試しやすい場所はない。顧客は自分。

追記: 資料が公開されました

デブサミ2014「グリーにおけるChef導入事例」講演メモ #devsumi


普段、Chefを使って運用しているので、なかなか参考になる話だったというか、共感できる部分が多かったです。


「グリーにおけるChef導入事例」

  • 荒井 良太 氏
    • @ryot_a_rai
  • グリー

Chefとは

  • サーバの構築や設定更新を自動化するツール
  • サーバのあるべき姿をRubyで記述しておくと、セットアップしてくれる
  • 冪等性
  • Chef社のOSS

導入背景

運用担当者が秘伝の手順書でサーバのセットアップを手動でやっていた。

  • 非効率
  • オペレーションミスの危険
    • Chefにより自動化し、安定運用をはかる
  • リードタイム
    • Chefにより自動化し、サーバのデリバリーを素早く行う

Before Chef

  • Debianパッケージ
    • サーバの役割ごとのメタパッケージ
  • 設定ファイルはスクリプトで生成
  • 設定値
    • パッケージ内
    • サーバ管理システムに問い合わせ

サーバ管理システム

  • 社内のサーバ情報を管理しているシステム
    • サーバ名とかデータセンター、サーバの状態。どのプロダクトで利用されているか
  • 運用スクリプト・ツールが依存している
    • システムを使える状態にしておかないと、運用ツールが動かない

導入方針

  • 新規のサーバをChefで構築していく
  • 既存のサーバ管理システムを利用する
  • 既存のツール・スクリプトが動く状態で移行する

導入する

  • Chefの挙動の話。(メモは割愛)
    • Chef Overview
    • Chef Solo/Chef Server

Chef Serverを使っていたのだけど、やめてChef Soloにしました。(!)


Chef Serverをやめた理由

  • 単一障害点になる
    • 冗長構成はサポートされていない(有償版だとできる模様)
  • サーバ管理が重複する
    • 既存のサーバ管理システムと役割が重複
  • 運用
    • 多数のソフトウェアが動いていてヘビー
    • (Erlangを使える人がいない)
      • Chef Server自体がErlangで作られている

Chef Solo + α

サーバ管理システム <-> Chef Bridge(内製) <-> GREE Chef Client(内製) <-> Chef Solo

Chef Bridge

  • Railsアプリケーション
  • 内製の簡易Chef Serverみたいなもの
    • クックブックやロール、ノードの属性を管理
  • HTTP API
    • 参照のみ
  • サーバ管理システムへの問い合わせ

GREE Chef Client

  • Chef Soloのラッパー
  • Chef Bridgeから必要な情報を取得
  • Chef Soloを実行
  • 自動テストも実行

コミュニティクックブック?

  • 非常に汎用的に作られている
    • 様々なOS、環境で動くように
    • 結果、複雑になりがち
  • 基本的に自社でクックブックを作っている

Chef入門

  • Chefは最近出てきたツール
  • Chefは学習コストが高いといわれる
  • Chef使いを育てる必要がある

Chef使いを養成する

  • 入門Chef Soloを読んでもらう
  • 初心者Chefアンチパターン by Julian Dunn
  • 社内用チュートリアル
    • クックブックを1つ作る
  • 公式ドキュメント
    • 特にresources

クックブックの開発

  • テストを書く
  • GitHub / Pull Request
  • 継続的インテグレーション

これから1つずつ解説。


テスト

  • クックブックを作った人が必ずテストも書く
  • serverspec / Test Kitchen
    • ブラックボックステスト
  • chefspec
    • ホワイトボックステスト
  • Foodcritic
    • Lintツール

なぜテストを書くのか

  • 開発を後押しする
    • TDD的な
    • SSHでログインして実行して、、、みたいな手動作業が煩雑
  • リグレッションを防ぐ
  • ドキュメント代わり
    • 構築後の姿がわかりやすい
  • 本番サーバの構築テスト
    • 本番環境でChefを実行した後にもテストを実行

serverspec

  • サーバのあるべき状態を記述して(テストケース)その状態になっているかをテストするツール

Test Kitchen

  • テスト対象の環境を記述し、その環境でテストできる
    • 複数の開発者が同じ環境でテストが行える

(1)Jenkinsサーバにつながらなくなった問題

  • ある日急に疎通しなくなった
  • 原因: ネットワークのルーティングが変わった
    • Virtual BoxのHost-only network

(2)Mutable Infrastructure問題

  • 繰り返しサーバに変更を加えるインフラ
  • serverspecを本番サーバで実行している
  • レシピごとにspecファイルを作る

(3)テストに時間がかかる問題

  • 細かくテストをまわさなくなる
  • テストケースを絞ってしまう
  • デプロイに時間がかかる

-----

  • VMの準備
    • VMのロールバック
    • LXC, Docker
  • Chefの実行に時間がかかるのは今後の課題

chefspec

  • chefspec はChef用のユニットテスティングフレームワーク
  • serverspecとかと同じテストは書かないようにしている

Foodcritic

  • クックブックのLintツール

GitHub

  • Pull Requestで変更を投げる
  • 変更に対するテストが通っているか確認
  • PullReq上で議論

継続的インテグレーション

  • Jenkinsを利用してCI
  • デプロイまで自動的に

ノードの属性

  • どのクックブックを使っているか
  • どのロールに属しているか
  • 構築サーバ対象の設定値
    • ノード設定のバリデーションも

ノード設定の共通化

  • ノード設定はYAMLで書く
  • YAMLのアンカーを使って参照

運用していく上で

構築ログが見たい時とかの話。

  • Chef以前は、script/screenコマンドのログをWikiとかにはりつけてた
  • 今は、ChefのReport Handlerを利用してログを送信
  • ログはDBへ保存(Fluentd, MongoDB)
  • ノードにログは残していない

(時間があったので終了後に質問させていただいた)

  • Chef Bridgeは冗長化している
    • 負荷分散と冗長化を同時に実現したかったので、2台たててDNS RRで運用している
    • 障害時のフェイルオーバーは、クライアント側でやっている(実行時にヘルスチェックを実施)
    • Chef Bridgeに負荷で捌けなくなることは、処理的な話とスケールできる仕組みがあるので大丈夫とのこと
  • 上記の話もあったので聞いてみたが、GREEさんでChefを使って運用している台数は50〜100台くらいだそうだ
    • 全体台数もこっそり聞いたら、(想像通りの)すごい数だったので、浸透はこれからの模様

追記: 資料が公開されました

デブサミ2014「サーバプロビジョニングのこれまでとこれから」講演メモ #devsumi


期待通り、面白い話だったのでメモを残しておく。


「サーバプロビジョニングのこれまでとこれから」

  • 宮下 剛輔 氏
    • mizzy
    • @gosukenator
  • paperboy&co.
    • テクニカルマネージャ

サーバプロビジョニングとは

プロビジョニングは3つのレイヤがある。

  • orchestration
    • application service orchestration
  • configuration
    • system configuration
  • bootstrapping
    • cloud or vm image launch
    • os install

あまり厳密に捉えすぎる必要はない。とのこと。


Bootstraping

今日は割愛


Configuration

  • ミドルウェアのインストールとか設定とか
  • いわゆる構成管理ツール
  • CFEngine, Puppet, Chef, Ansibleなど

会場は、Chef利用者多数っぽい。Puppetは少。


Orchestraion

インフラの概念と共に意味が変わって来ている。

詳しくは後で。


Infrastructure as Code

インフラをアプリケーション開発のようにコードで記述する。

この言葉が出始めたのはおそらく2008年ぐらい。

  • Puppet Next-Generation Configuration Managementという論文にも近い内容が記載。
  • 源流は1993年登場のCFEngine
  • 構成管理の4つの宣言
    • 宣言的「何をしたいかであって、どうするかではない」
    • 抽象化「あなたの代わりに詳細の面倒を見てくれる」
    • 冪等性「必要なときだけ実行する」
    • 収束化「放っておけばどうにかなる」

Infrastructure as Codeとは

  • ソースコードリポジトリ
  • アプリケーションバックアップ
  • サーバリソース

これらをゼロから再構築できるようにすること。

サーバ構築・運用におけるワークフローに変革をもたらすもの。


Infrastructure as CodeかたTest-Driven Infrastructure

  • テスト駆動インフラはChef周辺が盛り上がっている
  • Test-Driven Infrastructure with Chefという書籍もある
  • Test KitchenというツールもChef界隈から出てきている
  • Infrastructure as Codeを推し薦めてきたのがChef
  • Puppetに比べて、よりRubyっぽく記述できる
  • IaaSの台頭により、アプリ開発者がインフラを触れる機会が多くなってきた背景

みんながみんなChefを使っているわけではない。

そこで作ったのがserverspec。

serverspecの詳細は、WEB+DB PRESSのVol.76で!


テスト駆動インフラが駆動するのはインフラそのものではなくインフラを記述したコードを書くこと

テスト駆動インフラによるリファクタリング対象は、インフラの状態を記述したコード

インフラの状態を記述した「コード」をテストするためのツール


インフラCI

  • インフラのコードかとテストの自動化ときたら次はCI
  • ペパボはserverspecでテスト書いてJenkinsでまわしている
  • サービス例としてはとしては、WerckerとかTravisとか。今ホットになってきている

GitHub Flowによるインフラワークフロー

GitHub Fがインフラにも適用できるんじゃないか?ペパボでも取り組み始めている。

puppetマニフェストとかも、プルリクベースで。


Immutable Infrastructure (Disposable Components)

  • ImmutableよりもDisposableの方がむしろ重要
  • Immutableは不変という意味
  • 動いているサーバには変更を加えない
  • まったく新しくサーバを構築してロードバランサ等で切り替え
  • 成功したら元のサーバは「破棄」
  • Blue-Green Deploymentという名でも以前からテクニックとして存在する

Immutable Infrastructureでは

  • 変更に伴うトラブルが起こりにくい
  • 継続的改善がしやすい
  • 設計へのよい影響 "The Twelve-Factor App" / IX. Disposability
  • ChefやPuppetのようなツールがよりシンプルになる
    • 冪等性や収束化に従うために複雑になりがちだが、クリーンインストール前提だと考慮が少なくなる

Immutableにできないところ(永続的可変データを持つところ)はケースバイケース。

こういうところは、S3とかRDSのような外部に委ねるのも1つの手。


Container Base Deployment

  • コンテナ?=単機能・軽量なVM (とここでは便宜上定義)
  • コンテナをまるごとアップロードして差し替えること
  • Dockerの持つポータビリティによって実現可能性が高まった
  • ポータブルなのでローカル環境と本番環境で同じ環境が使える
  • つまりローカルで十分テストした後に、そのままでプロイすることができる
  • テスト駆動 -> CI -> デプロイ
  • 1コンテナ1機能と単純化して、サーバ部品のコンポーネントして扱う
  • コンポーネント化が進むことで個別に差し替えやすくなるので継続的改善がしやすくなる
  • 単機能かにより、テスタビリティも向上
  • IaaSじゃなくてもBlue-Green Deploymentができる
  • 今後、Mesos/YARN等の組み合わせで自動的なリソース配置最適化もできるようになってくる

Orchestration

  • Configuration
    • 単一のサーバで完結するもの
      • Apacheのインストール設定など
  • Orchestration
    • 複数のサーバが関連するもの
      • ロードバランサへのノード追加
      • muninやnagiosへのノード追加
      • アプリケーションデプロイ

旧来のOrchestraion

  • Immutable Infrastructure前提ではない世界
  • サーバの増減が頻繁ではないので、Configurationの領域でもやれてしまう
  • Command & Control

新しいOrchestraion

  • Immutable Infrastructure前提の世界
  • サーバの増減が頻繁なので、Configurationでの対応はきつい
  • Autonomy/自律協調

Serfの登場

  • ノードが追加されたら、**にノード追加が実現できる
    • 例: ロードバランサ、監視ツール等
  • 特徴
    • ノードのクラスタリング
    • ゴシッププロトコル
    • イベントプロパゲーション

SerfでやれることやるべきことをOrchestrationと捉えるとわかりやすい。

それによりOrchestration/Configurationの区別が明確になる。

OrchestrationをSerfに任せるとConfigurationがシンプルにできるかも。


追記: 資料が公開されました

2014/02/06

Zabbix統合監視 徹底活用

「Zabbix統合監視 徹底活用」を読んだ


OSSの統合監視ツールの1つであるZabbixに関する活用本。

大変ありがたいことに、著者/出版者様よりご献本いただきました。いつもありがとうございます。

本書はZabbixの最新バージョンである2.2系に対応しているとのことです。



ページを開けて読み始めると、第1章は物理・仮想・クラウド環境の概要というところで、2014年の今、Zabbix本でこの章の解説は要らないんじゃないかとも思いましたが、そこはこの本が、それだけ丁寧に説明しているという証。第2章からは、物理・仮想・クラウドそれぞれの監視やその管理の考え方が書かれています。わかりやすく書かれているので、これから監視まわりに取り組む方は読んでおくとよいですね。

(本エントリの最後に目次を載せておきます。)


第6章からは、いよいよZabbix特有の使い方やテクニックの話になります。Zabbixの本として期待されている方は、このあたりから読むと良いと思います。

この本の面白いところは、第1〜5章で、物理・仮想・クラウド環境それぞれの話を丁寧に説明しているところからわかる通り、それぞれのプラットフォームごとにテクニックを記載しているところではないでしょうか。取り上げられているプラットフォームは、仮想環境はメインがVMware(vSphere)、Xen、KVM。クラウド環境がAWSといった具合です。

また、これらが混在している環境(ハイブリッド環境)についても話としてサポートされているのも良いですね。


また、結構インフラまわりでの最近のトレンドとの絡みが網羅されていたりして、CloudInitやChefを使ったZabbixエージェントの管理であったり、ログ管理のところではFluentdとの連携の話が出てきたり、AWSまわりではAmazon SES/SNSとの連携など、なかなか盛り沢山です。


僕は、過去に(随分昔ですが)Zabbixを試したけど、結局使い辛くてやめてしまったタイプなのですが、随分変わってきているみたいですし、これを機にもう一度触ってみようかと思っています。


余談

ここからは余談ですが、僕がTISという会社で働いていた頃に、僕のチームに新卒社員として入ってきてくれたのが、本書の筆者である池田氏でした。

池田氏って書くとむず痒いので、いつも通り、池田くん、と書くことにします。


その頃、僕のインフラチームには、現ソニックガーデンCIOの安達(あえて呼び捨て)がいて、彼に池田くんのOJTを任せていたのですが、彼がジョインしてしばらくして話す機会があった時に、「なんでもいいので、面白いと思う技術で、まずは1つでいいから会社で一番になれるものを作ってね。」と伝えました。社会人になりたての彼は少し戸惑っていた素振りを見せましたが、「わかりました。がんばります。」と答えてくれた記憶があります。


それからしばらくして、僕はチームを、そして会社を離れることになるのですが、そのうちZabbix界隈で池田くんの名前を聞くようになりました。たまに勉強会で顔をあわせたりすると、挨拶してくれて雑談したりするのですが、昨年の勉強会で会った時に、この本を書いているという話を聞きました。


僕のいたインフラチームでは、いわゆる研究開発部門に所属していたこともあって、テクニカルな面でエッジを効かせていくのはもちろんのこと、アウトプット(仕事の成果はもちろんですが、社内外でのレポーティングや講演も含みます)も重視していました。池田くんは、一緒に仕事した時間がそれほど長くなかったのですが、彼はチームの体制が変わっていく中、立派に成長していて、海外のカンファレンスで登壇していたり、こうして書籍としての素晴らしいアウトプットを見ると、本当に感慨深いものがあります。(僕が特別何かをしたというわけでは決してないのだけど。)


ちょっと、おっさん話になってしまいましたが、最後に私信を。

池田くん、書籍の出版おめでとう。これからのさらなる活躍も楽しみにしています。今度ゆっくり飲みにでもいきましょう!


それでは! =͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́


本書の目次

Part I 物理・仮想・クラウド環境運用の基礎知識
  第1章 多様化するインフラ環境
  第2章 物理環境の監視・管理
  第3章 仮想環境の監視・管理
  第4章 クラウド環境の監視・管理
  第5章 物理・仮想・クラウド混在環境の監視・管理

Part II Zabbixによる物理・仮想・クラウド混在環境の統合管理
  第6章 Zabbixの監視のしくみ
  第7章 監視の効率性向上
  第8章 構成管理の効率性向上
  第9章 設定ファイル、ソフトウェアパッケージ管理の効率性向上
  第10章 ログ管理の効率性向上
  第11章 環境操作の効率性向上
  第12章 HyClops for Zabbixの概要

Appendix

2014/02/05

MySQLのホストキャッシュ


MySQL 5.5ホストキャッシュに関するメモ。

詳細は以下ドキュメントに全て書いてある。(英文)


シーケンス

  • 新しいクライアントから接続があると、サーバはそのIPアドレスからホスト名がホストキャッシュにあるかチェックする。
  • 無ければ、サーバはホスト名を解決することを試みる。
  • まず、IPアドレスからホスト名をチェックし、そしてホスト名からIPアドレスをチェックする。で、その結果をオリジナルのIPアドレスと比較し、同じであることを確認した後、ホストキャッシュに格納する。
  • キャッシュが一杯の場合は、最も長い時間使われていないエントリが破棄される。

名前解決

  • OSがサポートしている場合、スレッドセーフな gethostbyaddr_r() や gethostbyname_r() をコールする。
  • そうでなければ、MUTEXをロックして、代わりに gethostbyaddr() や gethostbyname() をコールする。
  • この場合、MUTEXロックが解放されるまで、他のスレッドはホストキャッシュにないホスト名の名前解決ができない。

利用目的

  • キャッシュを使うことで、サーバは各クライアントから接続がある度にDNS参照を行わなくなる。(初回の接続時にDNS参照する。)
  • キャッシュは接続中に生じたエラーの情報を含んでいる。このいくつかのエラーは"blocking"であり、サーバは接続エラーが多く発生したホストからの接続を拒む。これらは max_connect_errors のパラメータで許容するエラーの数を調整できる。詳しくはこちら「no title

ホストキャッシュのフラッシュ

  • ブロックされたホストを解除するには、 FLUSH HOSTS ステートメントを発行するか、 mysqladmin flush-hosts コマンドを実行することで、ホストキャッシュをフラッシュすることができる。
  • キャッシュ内に情報が存在しないホスト(クライアントIP)からの接続があった際、キャッシュが一杯(Full)の場合は、最も古い(未使用時間が最も長い)ホストのキャッシュエントリが廃棄される。
  • もし古いキャッシュエントリがブロックされたホストだった場合、そのホストはキャッシュから消えているのでアンブロック扱いとなる。

ホストキャッシュの有効/無効

  • ホストキャッシュはデフォルトで有効となっている。
  • 無効にしたい場合は、サーバの起動時に --skip-host-cache オプションを付ける。

その他パフォーマンス等

  • ホスト解決のためのDNS参照を無効にしたい場合は、サーバの起動時に --skip-name-resolve オプションを付ける。この場合、サーバは接続ホストの判別を、ホスト名ではなくIPアドレスだけを使用する。
  • もし、多くのホストとすげー遅いDNSを持っている場合、DNS参照を無効にするか、"HOST_CACHE_SIZE"の定義値を増やす(デフォルトは128、変更時はリコンパイルが必要)ことでパフォーマンスが改善するかもしれない。
  • 完全にTCP/IP接続を許可しない場合は、サーバの起動時に --skip-networking オプションを付ける。

以上。それでは! =͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́



オススメ (一部は、最近読んでいる本とも言う)
Chef実践入門 ~コードによるインフラ構成の自動化 (WEB+DB PRESS plus) クラウド Amazon EC2/S3のすべて~実践者から学ぶ設計/構築/運用ノウハウ~ [Web開発者のための]大規模サービス技術入門 ―データ構造、メモリ、OS、DB、サーバ/インフラ (WEB+DB PRESS plusシリーズ) エキスパートのためのMySQL[運用+管理]トラブルシューティングガイド [24時間365日] サーバ/インフラを支える技術 ~スケーラビリティ、ハイパフォーマンス、省力運用 Linux-DB システム構築/運用入門 (DB Magazine SELECTION) キャパシティプランニング ― リソースを最大限に活かすサイト分析・予測・配置 スケーラブルWebサイト 実践ハイパフォーマンスMySQL 第3版 ウェブオペレーション ―サイト運用管理の実践テクニック (THEORY/IN/PRACTICE) SQLアンチパターン インターネットのカタチ―もろさが織り成す粘り強い世界― ハイパフォーマンス ブラウザネットワーキング ―ネットワークアプリケーションのためのパフォーマンス最適化 Linuxの教科書―ホントに読んでほしいroot入門講座 (IDGムックシリーズ)