Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

インフラエンジニアになろう!

6,217 views

Published on

2009.6.6にAIIT(産業技術大学院大学)にて、学生会主催の勉強会で話した内容です

  • Be the first to comment

インフラエンジニアになろう!

  1. 1. インフラエンジニアになろう! netmark.jp all rights reserved
  2. 2. 自己紹介 ● 馬場俊彰(ばばとしあき) – id:netmarkjp – blog: http://netmark.jp/ – twitter: toshiak_netmark ● インフラエンジニア ● 情報処理技術者:TE-DB ● Javaプログラマーをしてたこともあります ● 株式会社ハートビーツのCTO netmark.jp all rights reserved
  3. 3. 今日のテーマ インフラエンジニア になろう! netmark.jp all rights reserved
  4. 4. 市場調査 Q.インフラエンジニア ってなんでしょう? 1.ネットワークエンジニア 2.サーバーエンジニア 3.オペレーター 4.運用の人 5.道路工事したりトンネル掘ったりする人 6.その他 netmark.jp all rights reserved
  5. 5. 正解は 6.その他 ● ネットワークエンジニア かつ ● サーバーエンジニア かつ ● アーキテクト かつ ● コンサルタント ※「私が考えるところの」インフラエンジニア像です netmark.jp all rights reserved
  6. 6. 守備範囲の実際のトコロ(役割) ● サービス運営をIT技術者としてサポート ● 人間がやるべきことに集中できようにするためのシステム ● アイデアの実現をIT技術者としてサポート ● 組み合わせれば意外と簡単!にできたりするモンです ● 困ったときになんとかする人 ● 平たく言うと障害対応 ● 初見でもたいがいなんとかします(でも無理なものは無理) ● 全体を理解しているからこそできることがある ★正確で迅速な切り分け ★的確な解決・回避 netmark.jp all rights reserved
  7. 7. 守備範囲の実際のトコロ(実務) ● 設計・・・機能分割、ソフトウェア、ミドルウェア、サーバ、ネットワーク、ネット ワーク、相互連携 ● 構築・・・機器設定、OSセットアップ、ミドルウェア設定、ソフトウェアチュー ニング、相互連携設定 ● 運用・・・非定型・非定例作業 ※定例・定形作業は基本的に自動化 ● 監視・・・システムがビジネス要求を満たしていることをチェック。ハード/ソ フト/サービスの状況を逐次確認し、障害・異常発見時には対応実施 ● 管理・・・システム設定変更、セキュリティ設定・維持、バックアップ ● 提案・コンサルティング・・・現在のシステムをよくわかっている立場か ら、状況改善をご提案 ● 障害対応コンサルティング・・・現在抱えているトラブルを解消・回避 するお手伝い netmark.jp all rights reserved
  8. 8. 守備範囲の実際のトコロ(技術) ● ネットワーク系 ● テクノロジー ● L1~L7 ● RDB,Key/Value ● HTTP(S)、DNS、メール、PKIの ● アーキテクチャ しくみ・・・ ● 高可用性設計と実現 ● サーバ系 ● 負荷分散設計と実現 ● 電源 ● セキュリティ ● ハードウェア, OS ● クラウド ● ミドルウェア ● 運用設計 ● 特徴,設定,チューニング... ● 運用作業 ● アプリケーション ● メンテナンス性 ● セッションパーシステンス,O/R, ● バックアップ・係数取得 キューイング... ● HTML,CSS,AJAX... netmark.jp all rights reserved ● Railsの特徴、 symfony、Strutsの特徴... ● SEO,集合知...
  9. 9. 何が楽しいの? ● インフラエンジニア って何が楽しいんでしょう? ● 代表的な例。。。たとえばプログラマーの場合 ● システムを完成させて納品したときの達成感 ● システムがC/Oしたときのドキドキ ● お客さんからお礼を言われたときの感動 ● などなど・・・ ● というか・・・・・・ITって何が楽しいんでしょう!? netmark.jp all rights reserved
  10. 10. ITの何が楽しいの? 夢があるよね! ● 自分の力でたくさんの人の心を動かせる! ● 自分の力でたくさんの人を幸せにできる! ● 世界を動かすことだってできる! ● 学ぶ・創る がずっとできる! netmark.jp all rights reserved
  11. 11. インフラエンジニアの楽しみ ● システムを(本当に物理レイヤーから)作り上げる ● すべて納得した上でシステムを作れます ● しくみを作って動かす ● 自分の作ったしくみが、時には数万人に利用されるドキドキ ● サービスを支え・育てる! ● サービスとして何が大事なのか、運営者とともに考えて実践 していきます ● ビジネスを支え・育てる! 口だけじゃない! ● システムは、動き出してからようやく価値を生み始めます システムと一緒に成長する、まるで親になった気分! netmark.jp all rights reserved
  12. 12. インフラエンジニアの苦しみ ● 「動いて当たり前」だけど 「動いて当たり前」じゃないんですよ! ● 何もしなくても動かなくなるんです ※何もしなくても動き続けるのは使われないシステムだけ! ● 基盤が止まると全部止まるプレッシャー ● システムの稼動時間=インフラエンジニアの稼動時間 ● たまに深夜早朝に出動するときもあります ● なぜか低く見られがち ● 運用に入ったら予算がない、とか ● システムで一体何がしたかったのか。。。 netmark.jp all rights reserved
  13. 13. いつも考えていること ● リーズナブル! ● スピード感が状況にマッチしていること! ● 費用対効果が状況にマッチしていること! ● 設計(特に拡張性)がビジネスの計画にマッチしていること! netmark.jp all rights reserved
  14. 14. いつも考えていること(2) ● オープンであること! ● 誰かの役に立つことが喜び ● 互助的な側面 ● オープンでないものは怖くて使えない – 大切なものは、主体者が掌握しておくべき – データ資産が囲い込まれる不安 – データ活用の道が閉ざされる不満 netmark.jp all rights reserved
  15. 15. どうやったらインフラエンジニアになれるの? 1.始めること!自ら動くこと! 2.楽しむこと! ● 実装は中古PCとLANで始められます ダイナミックDNSもあります 自宅サーバでもなんでもやってみることです ● いまは情報が豊富になりました ● 言い訳ばっかりして動かない人、教えてもらわないとできな い人は、残念ながら向いてません ● 経験がない状態で考えたってどうせわかんないんだから、 やってみよう! netmark.jp all rights reserved
  16. 16. 情報源 ● twitter ● man ● 勉強会・交流会 ● 各種公式ドキュメント ● blog/はてダ ● RFC ● ソースコード ● ML ● 書籍 ● Software Design ● WEB+DB Press ● サーバ/インフラを支える技術 (ISBN-10: 4774135666) netmark.jp all rights reserved
  17. 17. 将来性の話 ※ひとつの形です ITSSで言うところの – ITアーキテクト – ITスペシャリスト – アプリケーションスペシャリスト – ソフトウェアデベロップメント – ITサービスマネジメント をカバーして ● 地に足がついたアーキテクト になろう! netmark.jp all rights reserved
  18. 18. たとえば(1):メルマガ配信サービス 考慮すること・・・・ ● 性能 ・・・配信能力(チューニング、ブロック回避、実装方法) ● キャパシティ ・・・配信能力、負荷分散、データ量、、、 ● 可用性 ・・・機器冗長化、機能冗長化、、、 ● セキュリティ ● 個人情報保護 ・・・ACL、層分離、、、 ● ウィルスチェック ・・・実施タイミング・方法、、、 ● スパムチェック ・・・実施タイミング・方法、、、 ● 運用 ● メンテナンス ・・・停止、バックアップ、、、 ● リラン ・・・実現方法、実施方法、、、 netmark.jp all rights reserved
  19. 19. たとえば(1):メルマガ配信サービス 考慮事項の具体例・・・ ● ブロック回避 ● 逆引き設定、SPF、宛先精査・フィードバック、HELO/EHLO設定、、、 ● 構成 ● 複数拠点(別N/W)、IPアドレス数、、、 ● 負荷分散 ● 配信負荷分散、配信/管理サーバを分割、配信/管理NWを分割 ● 配信設定の配布方法の検討 – rsync, NFS, Replication Slave,,, netmark.jp all rights reserved
  20. 20. たとえば(2):メディアサイト 考慮事項の具体例・・・ヒット時は通常の10~20倍のアクセス、広告収入モデル ● 性能 ● 画面表示のレスポンスは快適にしたい ● ページのデータ量を減らす?→生命線なので無理 ● 画像の質を落とす?→落とせるものは落とす。落とせないものもある ● 広告・大きな画像はAJAXで非同期呼び出しにする?→広告は同期で! ● 広告は確実に配信したい→広告配信システムのチューニング ● 配信に特化したサーバ(web/広告)/CMSサーバ/広告配信サーバに分離 ● 可用性 ● サイトダウンはできるだけ避けたい→ロードバランサを構築して利用 もちろんOpenSource実装(Active - Hot Standby) ● キャパシティ ● アクセス数の増減がすさまじい・・・別回線にプチCDNを構築 netmark.jp all rights reserved
  21. 21. 事例紹介(3):ECサイト 考慮事項の具体例・・・セール時は通常の100倍のアクセス ● 性能 ● 快適に買い物できるように!→Web/Appサーバを分離 ● 可用性 ● サイトダウンはできるだけ避けたい – ロードバランサ、複数回線利用、セッションレプリケーション ● システムダウンはできるだけ避けたい – DBはHA構成 ● キャパシティ ● スケールアウト(Web/App/DB(Replication)を活用して水平分割 ● ファーミングなどの垂直分割も検討 netmark.jp all rights reserved
  22. 22. 余談:インフラエンジニアから見たクラウド ● 面白い ● オープン ● Closed実装のクラウドは怖くて・・・ ● Openであるからこそ提案できる – AWS - Eucalyptus, GAE - AppScale ● 発想の転換 ● 既存の知識・ノウハウは流用できる部分もある(特にIaaS) ● 「仮想化」とは違う - 集約 <=> 発散 ● 発想の異なる設計・管理(特にPaaS,SaaS) netmark.jp all rights reserved
  23. 23. 面白そうでしょ!? なにか 不思議に思ったことなどあれば ぜひ聞いてみてください netmark.jp all rights reserved
  24. 24. おしまい ご静聴いただきありがとうございました netmark.jp all rights reserved

×