昨日、ITインフラエンジニアの祭典「qpstudy」へ行ってきました。今回も、ノートを残しておきます。

幹事・発表者の皆様、会場を貸していただいたドワンゴさん、どうもありがとうございました!

概要

 第1セッション 構築作業の全体フェーズ
 第2セッション 今回の想定アーキテクチャとアーキテクチャ設計の勘所
 第3セッション ハードウェア設計の勘所
 第4セッション ネットワーク/OS設計の勘所
 第5セッション ミドルウェア(Web、Ap、DB)設計の勘所
 第6セッション 今後のインフラエンジニアとは

第1セッション 構築作業の全体フェーズ

しょっさん @sho7650

  • セッション全体の目標・ゴール
    • ITインフラエンジニアとして、業界の第一人者となるべく、知識と知恵を習得するきっかけを掴む。
    • ITインフラエンジニアのスコープを理解する。自分なりの答えを見つける。
    • (そして、自分自身は今後を見据えての知識の棚卸しに来ました。→自分はプロだと信じてるけど、それほどでもない人のゾーンだ。)
  • しゃべりながら黒板に書くのって、大変だwww 先生ってすごいね。
  • Why 〜 What 〜 How で流して行きます。しょっさんはWhatまで話します。
  • なぜインフラエンジニアは必要なのか?
    • そもそも昔はそんな言葉は無かった(少なくとも自分が働き出した頃はそうだったな)。
    • 「役割」と「範囲」… 要素を理解し、範囲を確認しよう。
    • エンジニアリングを理解しよう…問題解決。
    • スキルを理解しよう…ITSSマップをベースにしたスキルのロードマップの解説。
    • 技法(プラクティス)の理解。
    • ソフトウェア工学、特に開発プロセスの理解。まずはウォーターフォールモデルから。(そういえば中流って聞いた事無いな)
    • (EAみたら…www)
    • (開発プロセスを通じて、ITインフラエンジニアが関わる部分を解説していた。)
    • (追跡可能性の話をじっくりしていて、普段大切にされているのだろうな、と思った。)
    • (そういえば、プロセスの略称って会社によって微妙な違いがありますよね。)
  • まとめ: 特定のプロダクトに固執せず、必要なハードウェア・ソフトウェアを選択し構築・運用して行くのがITインフラエンジニアの仕事。
  • アプリの領域にも入って行く事が求められるのが、今後のITインフラエンジニア。

第2セッション 今回の想定アーキテクチャとアーキテクチャ設計の勘所

せちろーさん @sechiro

第3セッション ハードウェア設計の勘所

はせごーさん @hasegaw

  • CM: Fusion-IO
    • スライドの4ページ目、右側にスティーブ・ウォズニアックがいる。
  • 4日前に振られた。(でもちゃんと終えている所がすごい。)
  • クラウドでも、結局プログラムが動くのはハードウェアの上。だから、ハードウェアの事を知っておく事は大切。
  • プロセッサ
    • NUMA
      • (図の落とし方がきれいだなぁ〜)
    • Interconnect (MAX CPU数)
    • Memory Channel数
    • PCIeレーン数(GPGPUやる時重要)
    • コア数 vs クロック数
      • 上に乗っかるアプリの挙動をよく理解する。
      • ワークロード(実績)から考えよう。
  • メモリ
    • 枚数は少ない方が、良い事もある。何枚もさすと、クロックが落ちる製品が存在する。購入時、よく確認すること。
    • フラッシュメモリの話もあった。消費電力が少ないの、知らんやった。Pen 4のころのメモリアクセスくらいの速度は出る。
    • DRAMだけでまかなわず、フラッシュもあわせて使う事も考える。
  • NIC
  • ストレージ
    • サーバは壊れていてもいいのだが、データは壊れたらいけん。
    • コンピュータの中で一番遅い。
    • ストレージコントローラ
      • Partial Writeの問題。
      • 停電保護に、最近はBBWCばかりではなくFBWCもある。
      • FBWCでつかうフラッシュメモリの寿命は無視できるレベルらしい。(後でもうちょっと調べる)
  • 運用・保守
    • (オレオレ保守…ロードレーサーで愛三に走ってスイッチを買いに行った思い出がある。辛みある。)

第4セッション ネットワーク/OS設計の勘所

おおむらさん @yktko

  • CM: お気に入りの日本酒
  • 親父の小言
  • 感覚
    • レイヤ
    • 時間
    • トラブル
  • レイヤ感覚
    • NW (OSIをベースに)
    • ディスクアクセス
    • Kernel
  • 時間感覚
    • cronの罠
      • 1年後、それでいけるのか?
    • ログローテーション
    • 永遠は無い
      • OSのカウンタバグ: 208.5日とか
  • トラブル
    • 触診 – いろいろあるね
    • システムバックアップありますか?レストアできますか?
    • 屍 – 検死解剖:ログを取れ

第5セッション ミドルウェア(Web、Ap、DB)設計の勘所

ねこるりさん @nekoruri

  • 座席表: http://seats.nekoruri.jp/36
  • ミドルウェアの選択
    • 機能要件・非機能要件由来のもの
  • 実際の構築のパターンについてケース別に解説
  • 最もエキサイティング
    • 陳腐化が早い。
      • (でも、運用に乗ると年単位で残る事もまた事実。)
    • 考える事に注力する。
    • 使えるものは使う。
    • (たどっていくと、組織の仕組みに到達してしまう点は悩んでいる。)
  • See also: 先日、僕がDocker Meetup Tokyo #2へ行ってきた時のノートはこちら > 「Docker Meetup Tokyo #2 へ行ってきました #dockerjp

第6セッション 今後のインフラエンジニアとは

ばばさん @netmarkjp

  • インフラエンジニア養成読本、改訂新版でました!
    • ITインフラに関する知識、特に実務面を体系的に理解する事ができる本です。ぜひどうぞ。

ドワンゴさんタイム

  • 会議室のネットワークも、情報システム部の人が設計しているとのこと!
    • ニコ生もスムーズ!!!すごいっ!
    • 実際、ニコ生をスムーズに見られる事をちゃんと考慮しているそうです。
    • 会場提供、ありがとうございました。

おわりに

  • ITインフラに関する知識について、自分の理解が行き届いているか、そしてどこの理解が足りていないか、棚卸しするよい機会になりました。
    • タダで聞けるって相当ラッキーですよ。
    • 新人研修のトラックを1日に詰めたような、濃密な時間でした。
  • 長谷川さんのセッション、特に最近のハードウェアの動向をキャッチアップするのにとても参考になりました。電力消費の関係、もうちょっと掘らないとなー。
    • そして、僕はここをちゃんと人に話せる自信が無かった。
  • 特に、しょっさんのセッションが必要なのって、大学とかで、ちゃんとソフトウェア工学を教えてないからなのだろうな、と思いました。 (情報系の4年制大学へ行っていない人の感想です)
    • コンピュータサイエンスを学ぶ事は大切です。そして、同じくらいソフトウェア工学を学ぶ事がいいのではと思っております。まずは、ざっくりと。玉井先生の本がわかりやすいんだけれど、絶版だぁ…orz そこで、玉井先生&中谷先生が書いた放送大学の教材をぜひどうぞ。
  • 一人Chef問題、なかなか頭が痛い。プログラム自体はたいした事は無いけど、プログラムを書く事自体をどうやって興味を持ってもらうか、いろいろ取り組まないとな。
    • Chef関連の情報交換、最近滞ってる自分がいる。
  • 懇親会が楽しい。みんなもっとくればいいのに。
  • Togetter: qpstudy 2014.04 〜俺の屍を超えて行け、でも踏まないで〜 #qpstudy

皆様、お楽しみ様でした!!!