昨日、ITインフラエンジニアの祭典「qpstudy」へ行ってきました。今回も、ノートを残しておきます。
幹事・発表者の皆様、会場を貸していただいたドワンゴさん、どうもありがとうございました!
概要
- 2014-04-19
- @ドワンゴ 本社 (歌舞伎座)
第1セッション 構築作業の全体フェーズ 第2セッション 今回の想定アーキテクチャとアーキテクチャ設計の勘所 第3セッション ハードウェア設計の勘所 第4セッション ネットワーク/OS設計の勘所 第5セッション ミドルウェア(Web、Ap、DB)設計の勘所 第6セッション 今後のインフラエンジニアとは
第1セッション 構築作業の全体フェーズ
しょっさん @sho7650
- セッション全体の目標・ゴール
- ITインフラエンジニアとして、業界の第一人者となるべく、知識と知恵を習得するきっかけを掴む。
- ITインフラエンジニアのスコープを理解する。自分なりの答えを見つける。
- (そして、自分自身は今後を見据えての知識の棚卸しに来ました。→自分はプロだと信じてるけど、それほどでもない人のゾーンだ。)
- しゃべりながら黒板に書くのって、大変だwww 先生ってすごいね。
- Why 〜 What 〜 How で流して行きます。しょっさんはWhatまで話します。
- なぜインフラエンジニアは必要なのか?
- そもそも昔はそんな言葉は無かった(少なくとも自分が働き出した頃はそうだったな)。
- 「役割」と「範囲」… 要素を理解し、範囲を確認しよう。
- エンジニアリングを理解しよう…問題解決。
- スキルを理解しよう…ITSSマップをベースにしたスキルのロードマップの解説。
- 技法(プラクティス)の理解。
- ソフトウェア工学、特に開発プロセスの理解。まずはウォーターフォールモデルから。(そういえば中流って聞いた事無いな)
- (EAみたら…www)
- (開発プロセスを通じて、ITインフラエンジニアが関わる部分を解説していた。)
- (追跡可能性の話をじっくりしていて、普段大切にされているのだろうな、と思った。)
- See also: IEEE Std 830-1998
- (そういえば、プロセスの略称って会社によって微妙な違いがありますよね。)
- まとめ: 特定のプロダクトに固執せず、必要なハードウェア・ソフトウェアを選択し構築・運用して行くのがITインフラエンジニアの仕事。
- アプリの領域にも入って行く事が求められるのが、今後のITインフラエンジニア。
第2セッション 今回の想定アーキテクチャとアーキテクチャ設計の勘所
せちろーさん @sechiro
- 守破離
- ITインフラに置ける守破離とは?
- まずは、先人の知恵である「型」を理解…「守」からはじめよう。
- See Also: インフラデザインパターン ~安定稼動に導く127の設計方式
- ITインフラエンジニアの設計のパターンとは?
- 「機能要件→アプリから」+非機能要件→インフラ要件 (アプリの人だったので実はインフラだけってのは考えた事が無かった)
- プラスα: AWS CDP
- See Also: Amazon Web Services クラウドデザインパターン 設計ガイド
- CM: インフラエンジニアかるた、よろしく!!!
- 機能要件
- アプリケーション設計の一般的な話が進んでいる。
- 2回目のCM、カットされた。
- 非機能要件
- 経験を求められる。過去の設計を参考にする。
- IPAの非機能要求グレードを参考にしましょう。
- See also: エンタプライズ系事業/非機能要求グレード:IPA 独立行政法人 情報処理推進機構
- 2時間問題
- 教育
- 1人Chef問題…
- (運用でカバー・ワークアラウンドに頼るのは甘え。)
- 「なれる!SE」は、休みの時に読むと辛いらしい。
- 説明責任
- ITインフラエンジニアは最後の砦
- Azusa テンプレ使いました!
第3セッション ハードウェア設計の勘所
はせごーさん @hasegaw
- CM: Fusion-IO
- スライドの4ページ目、右側にスティーブ・ウォズニアックがいる。
- 4日前に振られた。(でもちゃんと終えている所がすごい。)
- クラウドでも、結局プログラムが動くのはハードウェアの上。だから、ハードウェアの事を知っておく事は大切。
- プロセッサ
- NUMA
- (図の落とし方がきれいだなぁ〜)
- Interconnect (MAX CPU数)
- Memory Channel数
- PCIeレーン数(GPGPUやる時重要)
- コア数 vs クロック数
- 上に乗っかるアプリの挙動をよく理解する。
- ワークロード(実績)から考えよう。
- NUMA
- メモリ
- 枚数は少ない方が、良い事もある。何枚もさすと、クロックが落ちる製品が存在する。購入時、よく確認すること。
- フラッシュメモリの話もあった。消費電力が少ないの、知らんやった。Pen 4のころのメモリアクセスくらいの速度は出る。
- DRAMだけでまかなわず、フラッシュもあわせて使う事も考える。
- NIC
- TPS, Latency は、 GbE < 10G
- See Also: Solarflare_Accelerates_Memcached.pdf
- 10Gは身近になってきたよ!
- Memcachedなど、これでパフォーマンスがあげられる事を覚えとく。
- 当然、帯域幅も広がる。
- See Also: オンラインゲームを用いたネットワーク品質の大規模計測 – 距離から来る遅延について、グランツーリスモをベースに調査されている論文です。
- TPS, Latency は、 GbE < 10G
- ストレージ
- サーバは壊れていてもいいのだが、データは壊れたらいけん。
- コンピュータの中で一番遅い。
- ストレージコントローラ
- Partial Writeの問題。
- 停電保護に、最近はBBWCばかりではなくFBWCもある。
- FBWCでつかうフラッシュメモリの寿命は無視できるレベルらしい。(後でもうちょっと調べる)
- 運用・保守
- (オレオレ保守…ロードレーサーで愛三に走ってスイッチを買いに行った思い出がある。辛みある。)
第4セッション ネットワーク/OS設計の勘所
おおむらさん @yktko
- CM: お気に入りの日本酒
- 親父の小言
- 感覚
- レイヤ
- 時間
- トラブル
- レイヤ感覚
- NW (OSIをベースに)
- ディスクアクセス
- Kernel
- 時間感覚
- cronの罠
- 1年後、それでいけるのか?
- ログローテーション
- 永遠は無い
- OSのカウンタバグ: 208.5日とか
- cronの罠
- トラブル
- 触診 – いろいろあるね
- システムバックアップありますか?レストアできますか?
- 屍 – 検死解剖:ログを取れ
第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週間前に振られているwww
- 新人さんへの応援メッセージ
- 鯵
- だけじゃないよ
- 実践しよう!
- 本、紹介していただいてありがとうございました!(´;ω;`)
- Web技術の基礎〜プログラミング〜開発〜構築〜運用まで一気通貫で学べるようにした本です。もしよかったらどうぞ!
Webアプリエンジニア養成読本[しくみ、開発、環境構築・運用…全体像を最新知識で最初から! ] (Software Design plus)
posted with amazlet at 14.04.20和田 裕介 石田 絢一 (uzulla) すがわら まさのり 斎藤 祐一郎
技術評論社
売り上げランキング: 3,160
- Web技術の基礎〜プログラミング〜開発〜構築〜運用まで一気通貫で学べるようにした本です。もしよかったらどうぞ!
ドワンゴさんタイム
- 会議室のネットワークも、情報システム部の人が設計しているとのこと!
- ニコ生もスムーズ!!!すごいっ!
- 実際、ニコ生をスムーズに見られる事をちゃんと考慮しているそうです。
- 会場提供、ありがとうございました。
おわりに
- ITインフラに関する知識について、自分の理解が行き届いているか、そしてどこの理解が足りていないか、棚卸しするよい機会になりました。
- タダで聞けるって相当ラッキーですよ。
- 新人研修のトラックを1日に詰めたような、濃密な時間でした。
- 長谷川さんのセッション、特に最近のハードウェアの動向をキャッチアップするのにとても参考になりました。電力消費の関係、もうちょっと掘らないとなー。
- そして、僕はここをちゃんと人に話せる自信が無かった。
- 特に、しょっさんのセッションが必要なのって、大学とかで、ちゃんとソフトウェア工学を教えてないからなのだろうな、と思いました。 (情報系の4年制大学へ行っていない人の感想です)
- コンピュータサイエンスを学ぶ事は大切です。そして、同じくらいソフトウェア工学を学ぶ事がいいのではと思っております。まずは、ざっくりと。玉井先生の本がわかりやすいんだけれど、絶版だぁ…orz そこで、玉井先生&中谷先生が書いた放送大学の教材をぜひどうぞ。
- コンピュータサイエンスを学ぶ事は大切です。そして、同じくらいソフトウェア工学を学ぶ事がいいのではと思っております。まずは、ざっくりと。玉井先生の本がわかりやすいんだけれど、絶版だぁ…orz そこで、玉井先生&中谷先生が書いた放送大学の教材をぜひどうぞ。
- 一人Chef問題、なかなか頭が痛い。プログラム自体はたいした事は無いけど、プログラムを書く事自体をどうやって興味を持ってもらうか、いろいろ取り組まないとな。
- Chef関連の情報交換、最近滞ってる自分がいる。
- 懇親会が楽しい。みんなもっとくればいいのに。
- Togetter: qpstudy 2014.04 〜俺の屍を超えて行け、でも踏まないで〜 #qpstudy
皆様、お楽しみ様でした!!!