注目の記事

Immutable Infrastructure Conference #1 に参加してきた #immutableinfra

しんや

2014.03.26

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

最近は最早バズワード化した感も充分ある『Immutable Infrastructure』。この長〜いフレーズを発音する際に途中発音を噛む人が後を絶たない今日この頃、皆様いかがお過ごしでしょうか。(発音に悩んでいる、何とか噛まないようにしたい！という方は以下のエントリを参考にしてみる事をお勧めします)

さて、本題です。こちらの『Immutable Infrastructure Conference #1』、発表と同時に参加応募者が殺到し、最終的には150人の参加定員に450人近くが応募、約300人が溢れてしまうという何とも物凄い事態に。同じ様な系統・同時期開催(こちらは4/11)の勉強会に以下『Docker Meetup Tokyo #2』がありますが、こちらは現在100人の定員になんと400人の参加申込み！この辺りのインフラ界隈のテーマに関する注目度の高さを物語ってますね。

そんな注目度抜群な当イベントについて、タイミング良く募集開始の報せを知る事が出来参加申込みｽﾞｻｰc⌒っﾟДﾟ)っする事が出来たので参加して来ました。ざっくりではありますが当エントリではその内容についてメモを書き連ねて行こうと思います。

開催会場はDeNA＠渋谷ヒカリエ。

hikarie

hikarie2

目次

講演

Immutable Infrastructureが開発プロセスに与える影響(仮)

ii_ito_naoya_01

スライド資料

講演内容メモ：

  • 苦節数年、私もついにDeNAオフィスで話す事ができて感慨深い…!w
  • JAWS DAYS参加された方がいるがそこと被る話もありつつ、Immutable Infrastructureの概要やテーマについて。アプリよりの視点からImmutable Infrastructureについて見てみよう、というのが趣旨。
  • Disposable components...だとバズワード感が足りない？450人集まらない？w
  • 不変な、状態を持たない、廃棄可能な、と言ったほうがより現実を表している？
  • サーバの状態、半年ぶりに行うRailsアプリのデプロイ。それ動くのか・果たしてデプロイは正しく終わるのか？
  • 管理する手段：手順書/自動化/サーバー管理DB/Chef/Puppet...？
  • サーバー状態をコードで管理出来るようになった。
  • でも、状態管理が面倒ならしなくてもよい？→Immutable Infrastructureの始まり。
  • チャドファウラーの(有名なプログラマーの、って事しか知らないw)Blue Green Deploymentがこのテーマを語る上でわかりやすい。(詳細：「Blue-Green Deployment」とは何か、マーチン・ファウラー氏の解説 － Publickey)
  • 新しくLBを切り替える事で、トラフィックが切り替わる。ちなみにこれは仮想化環境が前提。オンデマンドで環境を作成し、プログラムを動かせる状態にしておく必要がある。なので自動化も必須。
  • まぁ、いわゆるアレですね...(と前置きし、数日前に盛り上がったという以下フレーズ画像を表示)
    • ii_ito_naoya_02
  • Herokuではgit pushする際、新しい環境(コンテナ)を作り、古い環境を棄てている。また、Travis CIもテストを実行する度、コンテナを作り終わったら棄てている。こういうのを採用すると、1時間に1000回デプロイする(AWS)ってのも出来るようになる。

Immutableになる影響について

  • 1.アーキテクチャの影響
    • ある意味不自由になる。アプリ開発者からすると今までのやり方が通用しなくなる。
    • 制約：制約は必ずしも悪いものではない。(例...REST, ステートレスなHTTPとWWWなど) 制約を受け入れる事でよい側面もある。
    • Immutableな制約がもたらす影響：アプリの設計にも良い影響を及ぼす。
  • 2.再現可能なアプリケーション
    • どこでも再現できる、というのは重要。**** as a serviceに放り込む事が出来る。
    • 開発環境とプロダクションを同一視出来、横展開のスケールが容易に。
    • テストを通ったらherokuとかにあげちゃえ、というサービスも出て来ている。
  • 3.テスト容易性
    • 再現可能かつステートレスかつシェアードナッシング。。。いかにもテストしやすい形に。
  • 4.上書きデプロイからコンテナベースのデプロイへ
  • まとめ：Immutable Infrastructureの現在
    • 開発者が試行錯誤を繰り返している状態。いろいろ必要な部分が作られている。
    • privateなpaaasが欲しい、ではなく、既存インフラの一部を動的にしたい、というユーザーが注目
    • ユーザーはコンテナベースのデプロイの利益を体感し始めている
  • これから：
    • Immutable Infrastructureによって、今まで固定的だと考えていたコンポーネントが動的・オンザフライに。
    • 昨今のサーバ/インフラパラダイムとしての集大成として、色々な概念や実装がImmutable Infrastructureに集約されていくのでは。結果的にアプリ設計や実装も影響を受けて行くと思う。

Immutable InfrastructureとProvisioning Testing

ii_miyashita_gosuke_01

  • 自己紹介
    • mizzyとかの方がわかりやすいかも知れません。
    • serverspecを作ってます。
    • 今回はImInとServerのテストについて話します。というよりもコンテナと、Provisioning Testingについて話を。
  • Provisioning Testing、あまり聞いたことがない？耳慣れない言葉。→ソートワークス：テクノロジーレーダーの技術動向をまとめたホワイトペーパー。2014年1月版に項目が出て来ている。言葉の意味としては、アプリ開発に於けるTDDのようなものを応用したもの、の意。テクノロジーレーダー2012年02月版で、既にImmutable Serversという言葉が出て来ている。
  • コンテナとProvisioning Testingの関係
    • コンテナをテストに利用：既にやっている人も居るし、ブログエントリもある。
    • コンテナといえば、docker。これとセットで語られる事が多い。宮下氏自身、dockerがOSSになる頃にpuppetで同じ様な機能を作っていた。そしたらdocker２〜３日後に出て来て何だよ！となったw
    • ちなみにdockerもテクノロジーレイヤーに乗っている。
    • コンテナをテストに使うメリット＝軽量で起動が早く、リソースも少なく済む。結果テストサイクルが速くなる。
    • コンテナをテストに使う際のデメリット
      • マシンの仮想化ではない。OSの領域を区切る形。hypervisor的なものとは仕組みが異なる。
      • コンテナにも2通りの起動方法があり、システムコンテナとして起動すると普通のVMのように見えるが、微妙に違う部分があってはまる。
      • iptablesの制御ができない/ntpdが動かない等。
      • プロビジョニングで別if in_container みたいな処理が必要に。
      • ホストがubuntuでゲストがcentosという構成でハマったり。upstartやinit周りの挙動とか。
      • プロダクションがベアメタルやハイパーバイザー型マシンでテスト用リソースが豊富にあるなら、コンテナは無理にはお勧めしないが、止めもしません(笑)
  • コンテナをプロダクションで使う場合のProvisioning Testing
    • 1コンテナ、1サービスを。apache用コンテナ、nginxコンテナ….etcなど。システムコンテナに対してアプリケーションコンテナと呼ぶらしい。単機能・疎結合なコンテナを組み合わせてシステムを作る形。
    • ホストOSとコンテナの機能分離が実現可能に。先程出て来た不具合周り、コンテナの吐いたログを任すのはOSでも良くなる。
    • テストの分離：テスタビリティ向上にも貢献。コンテナがわはむしろテストが要らなくなる？状態のテストよりも振る舞いのテストが重要に。とはいえ振る舞いテストは要件ばらばらで、まだ決定的なルールはない状況。serverspec/specinfraをベースに作るかも？
  • まとめ
    • Provisioning Testingでのコンテナの利用：プロダクションがコンテナじゃないなら無理におすすめはしないが止めもしません。
    • プロダクションでコンテナを使う場合のProvisioning Testingはテスタビリティが向上、状態のテストよりも振る舞いのテストが重要だし、今後の課題でもある。

SerfというOrchestrationツール

スライド資料

講演内容メモ：

  • Serfというツールについて
    • Serf：オーケストレーションツールの一種。
    • serf-site
    • サーバー群のクラスタリング、ロードバランサに追加したり、監視を入れたり、サーバ管理ツールに登録したり、という他のツールと連携するための作業を行う。手でコマンド叩いたり。serfもここをカバー。
    • Blue-Green Deploymentの切替時に用いる。
    • インフラ作業あるある：諸々のオーケストレーション作業も、欠かせないタスク。
    • ii-101
    • オーケストレーション作業、1台でも面倒なのに100台一気に入れ替えるとか、1日10台BGdeploymentするとかなると…もう＼(^o^)／ｵﾜﾀ状態に。→serfで自動化！
    • 設定・実行例：Serf agentの起動/serf join/イベントハンドラ/Serfで/etc/hostsの更新
    • サーバが起動したら自動で監視設定、自動でサービスイン出来るように
  • 2つの『型』...氏曰く、『Agent型がImmutable Infrastrucureには向いている』という持論を持つ。
    • 中央集権型: nagios等
    • Agent型: Sensu等
    • ii-102
  • そして！
  • ii_sonots_01
  • その他思ったことやまとめなど
    • 実際、どの位の時間で伝播されるのか？→30ノードで1.25s、100ノードでも2s程。
    • イベントをどのノードに発火すべきか
    • ImmutableインフラにはAgent型が適している
    • Serfで中央集権型の仕組みをAgent型に変えると諸々捗る。

Mesosを使ったImmutable Infra管理システムを作ってみた

ii_watanabe_tatsuru_01

スライド資料

講演内容メモ：

  • 仮想化についてはdockerを前提に。テストやデプロイについてもjenkins/差分ビルド、serverspecを採用
  • クラスタ管理の話
    • 規模が小さければまだ手作業で管理出来るが、多くなると何らかの管理が必要に。
    • 自前であれば自前：1 active vmやhost、Serf等
    • 全部入りであればopsnstackやcloudfoundryなども視野に。
  • 今回はリソース管理システムとしてApache mesosを使ってみた。
  • mesosの話
    • クラスタ管理を以下要素で構成：Master/Slave,Framework(Marathon), Executor(Mesos-Docker)
    • 長時間サービスを動かすためにMarathonというフレームワークを使った。
    • 最近のmesos/marathonはapiがdockerに対応してたり、deimosがdocerの仕組みを組み込んだり。
    • 実際仕組みはどうなの？悪くはない。中身も見えるし。
    • ii-103
  • Log収集の話
    • fluentdを用いる。(コンテナ内supervisor経由で)
    • 最近、docker log に関する興味深い内容があった。→collection inside container
  • Metrics
    • サーバメトリクス：サーバが頻繁に入れ替わるので、サーバ単位ではダメ
    • ホストからcgroup,netstatを使う。
    • サービスのログについては従来通りの対応で。
    • まとめ：ホスト単位だと運用が難しい。agent型もありなのでは。台数課金なサービスはつらい。newrelicなど aggregationが課題
  • 皆大好き監視の話
    • sensuのスーパーバイザーをエージェント型で起動。
    • モニタリングのビジュアル化：sensuのエージェント型。ログと同じパターンで運用出来そう。helper containers
  • 全体の構成：オーケストレーション。まとめ約が必要。
    • ダッシュボード、マスタデータなど
    • アプリのリポジトリ
      • クラスタに持たせる - serf
      • 中央で管理する何か...aws elastic beanstalk/Newrelicで頑張る/自作 等
  • まとめ：
    • Immutable Infrastructure環境を作ってみた。
    • 課題もいろいろ。クラスタ管理/ログ集約/メトリクスモニタリング
    • この分野はこれだ! というツールがまだない印象。ドンドン作ってみましょう！そして色々教えてください。

Docker + HAProxy + Synapse

ii_narita_issei_01

mirakui氏：

『immutable waterを買って来たのですが、若干圧力を感じてます...w』

  • Synapse
    • airbnb/synapse
    • airbnbが作った、任意のサービスディスカバリをhaproxyに反映させるもの。
    • なぜSynapseか？
      • クックパッドでも同様にサービスディスカバリによってhaproxyを自動更新するという実装をしているので興味を持った。
      • Pure Rubyである事はありがたい！Rubyだから読めるし。Not Javaってところも(ry
    • クックパッドで行ってる事
      • 同じロールタグをもっているものにstatus:workingを付与し、working状態の内容によってサービスインを実行
      • Synapseの動作も同様にステータスで管理。起動もインストールも簡単。
  • ディスカバリの種類を設定ファイルで指定。
    • 対応しているディスカバリ：DNS/Docker/EC2 tag/Zookeeper
    • EC2、Tag対応してる？と思ったら動かない...良く見たら...コードがコメントアウトされたままにww (結局対応してませんでした！)

ii_narita_issei_02

↓

ii_narita_issei_04

そして実演デモへ。

ii_narita_issei_03

そして、

どうやらこれの模様。

  • まとめ・雑感
    • 動く。
    • ディスカバリと連携してhaproxyの設定を書き換えたりリロードしたりするという実装はオモシロイと思った
    • airhubやzookeeperを駆使しているなので、Zookeeperのwather以外の実装には興味ない？

Immutable Infrastructure時代のサーバー管理

ii_shinji_tanaka_01

スライド資料

講演内容メモ：

ii_shinji_tanaka_02

  • 自己紹介
    • はてなCTO
    • 『引き続いてイミュータブルな感じで行きたいと思います。』
  • サーバ管理といえば…
    • zabix/nagios+munin/sensu/aws cloudwatch… いろいろあります
  • サーバ管理の基本
    • ホスト1台1台を認識、そのうえで用途やミドルウェアを認識
    • Blue Green Deployment: ホストが使い捨てられてしまう状態
    • Auto-scaling: ホストが勝手に増減してしまう
    • ※『ホスト』の流動性が高まってくる状態に。
  • Role Based Management
    • 役割でホスト集合を管理。ホスト名に意味を持たせない構成に。
    • サーバに名前を付けるという行為はもはや古い慣習、クラウドネイティブな試行を妨げる足かせになる。
  • 実装案
    • EC2のタグや、独自DBを整備。これで、ホスト群を集合的に扱えるようにする。
      • role="web","db"
      • Autoscalingでもタグが付与される
    • これで出来る事
      • デプロイ時のホスト一覧を取得
      • ホストへの一括sshログイン
      • 役割(＝ホスト集合)単位でのメトリクス情報可視化
  • ホスト集合と"世代"
    • 役割の他にも世代というものが増えてくる。
    • これで何が問題になるか？
      • サーバが存在しなくなってしまう為デプロイによりグラフが分断されてしまう。
      • 『昨日のグラフは存在しません』な事態に。
      • 古いデータを残しグラフ同士を繋げ、リソースグラフの連続性を持たせる：工夫が必要に。
    • ii_shinji_tanaka_02
  • デプロイプロセスとサーバ管理の融合
    • Immutable Infrastructureの良さを引き出す為に管理するサーバの単位を抽象化
    • より柔軟なホスト操作と集合を対象としたパフォーマンス管理
    • この辺、サービス化しようかなと思います！
    • ii-104

次いでLT。飛び入り参加者＋1名の計4名によるLTとなりました。

LT

LT: chefからdockerへの鞍替え / BRS (TwitterID:@xga)さん

xga

xga-01

LT: Docker使ってたらロードアベレージが80超えた話 / ゆううき (TwitterID:@y_uuk1)さん

LT: 実際にやってみた / ✌ʕ ◔౪◔ ʔ✌ (TwitterID:@katzchang)さん

Immutable Infrastructure周りのツールを現場で使ってみた際の『つらい』ポイントを列挙し発表。

katzchang-01

katzchang-02

LT: AWSを使った事例紹介 / ikikko@リアルJenkins (TwitterID:@ikikko)さん

飛び入り参戦。Immutable Infrastructure環境構築で取り組んだ内容についての解説。

ikikko-001

ikikko-02

まとめ

という訳で、記念すべき第1回目の勉強会の模様を振り返ってみました。この分野(フレーズ？)は最近一気に注目されている一方で、(登壇者の方々もコメントされてましたが)まだまだ試行錯誤や情報の共有や展開でより良い環境への改善へと繋げて行く取り組みも必要となっている状況です。私自身今回のキーワードもほぼ初見(見てはいたけど触ってはいなかった、という方が正しいか)な状況で臨んだので、その点では全ての内容がとても勉強になりました。会場ご提供頂いたDeNA関係者の皆様、登壇者の皆様ありがとうございました！

あわせて読みたい

スキルアップ|初心者向け|書評|デベキャン|AWS認定|スキルアップ|デベキャンだより|勉強会|コミュニティ

関連記事

【イベントレポート】筋肉エンジニアのビルドアップ会#4 に参加してきました

佐藤雅樹

2024.04.04

【イベントレポート】「Unreal Engine Meetup in Nagoya Season2 Vol.1」に参加してきました。

入井啓太

2024.03.24

ハックツハッカソン ~ブラキオカップ~ にメンターとして参加してきました

森田力

2024.03.22

「GitLab Connect Japan 2024」に参加してきました

きだぱん

2024.02.16