狠狠撸

狠狠撸Share a Scribd company logo
インフラエンジニアになろう!




    netmark.jp all rights reserved
自己紹介

●   馬場俊彰(ばばとしあき)
      –   id:netmarkjp
      –   blog: http://netmark.jp/
      –   twitter: toshiak_netmark
●   インフラエンジニア
●   情報処理技術者:TE-DB
●   Javaプログラマーをしてたこともあります
●   株式会社ハートビーツのCTO



                         netmark.jp all rights reserved
今日のテーマ




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

  netmark.jp all rights reserved
市場調査

Q.インフラエンジニア ってなんでしょう?
1.ネットワークエンジニア
2.サーバーエンジニア
3.オペレーター
4.運用の人
5.道路工事したりトンネル掘ったりする人
6.その他




              netmark.jp all rights reserved
正解は




              6.その他
●   ネットワークエンジニア かつ
●   サーバーエンジニア かつ
●   アーキテクト かつ
●   コンサルタント


    ※「私が考えるところの」インフラエンジニア像です
                netmark.jp all rights reserved
守備範囲の実際のトコロ(役割)

●   サービス運営をIT技術者としてサポート
    ●   人間がやるべきことに集中できようにするためのシステム
●   アイデアの実現をIT技術者としてサポート
    ●   組み合わせれば意外と簡単!にできたりするモンです
●   困ったときになんとかする人
    ●   平たく言うと障害対応
    ●   初見でもたいがいなんとかします(でも無理なものは無理)
    ●   全体を理解しているからこそできることがある
        ★正確で迅速な切り分け
        ★的確な解決?回避
                netmark.jp all rights reserved
守備範囲の実際のトコロ(実務)

●   設計???機能分割、ソフトウェア、ミドルウェア、サーバ、ネットワーク、ネット
    ワーク、相互連携
●   構築???機器設定、OSセットアップ、ミドルウェア設定、ソフトウェアチュー
    ニング、相互連携設定
●   運用???非定型?非定例作業 ※定例?定形作業は基本的に自動化
●   監視???システムがビジネス要求を満たしていることをチェック。ハード/ソ
    フト/サービスの状況を逐次確認し、障害?異常発見時には対応実施
●   管理???システム設定変更、セキュリティ設定?維持、バックアップ
●   提案?コンサルティング???現在のシステムをよくわかっている立場か
    ら、状況改善をご提案
●   障害対応コンサルティング???現在抱えているトラブルを解消?回避
    するお手伝い       netmark.jp all rights reserved
守備範囲の実際のトコロ(技術)
●   ネットワーク系                            ●   テクノロジー
    ●   L1~L7                              ●   RDB,Key/Value
    ●   HTTP(S)、DNS、メール、PKIの           ●   アーキテクチャ
        しくみ???                             ●   高可用性設計と実現
●   サーバ系                                   ●   負荷分散設計と実現
    ●   電源                                 ●   セキュリティ
    ●   ハードウェア, OS                         ●   クラウド
●   ミドルウェア                             ●   運用設計
    ●   特徴,設定,チューニング...                    ●   運用作業
●   アプリケーション                               ●   メンテナンス性
    ●   セッションパーシステンス,O/R,                  ●   バックアップ?係数取得
        キューイング...
                                       ●         HTML,CSS,AJAX...
                        netmark.jp all rights reserved
    ●   Railsの特徴、
        symfony、Strutsの特徴...           ●   SEO,集合知...
何が楽しいの?

●   インフラエンジニア って何が楽しいんでしょう?

●   代表的な例。。。たとえばプログラマーの場合
    ●   システムを完成させて納品したときの達成感
    ●   システムがC/Oしたときのドキドキ
    ●   お客さんからお礼を言われたときの感動
    ●   などなど???

●   というか??????ITって何が楽しいんでしょう!?

                  netmark.jp all rights reserved
滨罢の何が楽しいの?



           夢があるよね!
●   自分の力でたくさんの人の心を動かせる!
●   自分の力でたくさんの人を幸せにできる!
●   世界を動かすことだってできる!
●   学ぶ?創る がずっとできる!


             netmark.jp all rights reserved
インフラエンジニアの楽しみ

●   システムを(本当に物理レイヤーから)作り上げる
    ●   すべて納得した上でシステムを作れます
●   しくみを作って動かす
    ●   自分の作ったしくみが、時には数万人に利用されるドキドキ
●   サービスを支え?育てる!
    ●   サービスとして何が大事なのか、運営者とともに考えて実践
        していきます
●   ビジネスを支え?育てる!                            口だけじゃない!
    ●   システムは、動き出してからようやく価値を生み始めます
        システムと一緒に成長する、まるで親になった気分!
                netmark.jp all rights reserved
インフラエンジニアの苦しみ

●   「動いて当たり前」だけど
    「動いて当たり前」じゃないんですよ!
    ●   何もしなくても動かなくなるんです
        ※何もしなくても動き続けるのは使われないシステムだけ!
    ●   基盤が止まると全部止まるプレッシャー
●   システムの稼動時間=インフラエンジニアの稼動時間
    ●   たまに深夜早朝に出動するときもあります
●   なぜか低く見られがち
    ●   運用に入ったら予算がない、とか
    ●   システムで一体何がしたかったのか。。。
                netmark.jp all rights reserved
いつも考えていること

●   リーズナブル!
    ●   スピード感が状況にマッチしていること!
    ●   費用対効果が状況にマッチしていること!
    ●   設計(特に拡張性)がビジネスの計画にマッチしていること!




                netmark.jp all rights reserved
いつも考えていること(2)

●   オープンであること!
    ●   誰かの役に立つことが喜び
    ●   互助的な側面
    ●   オープンでないものは怖くて使えない
        –   大切なものは、主体者が掌握しておくべき
        –   データ資産が囲い込まれる不安
        –   データ活用の道が閉ざされる不満




                    netmark.jp all rights reserved
どうやったらインフラエンジニアになれるの?

1.始めること!自ら動くこと!
2.楽しむこと!
●   実装は中古PCとLANで始められます
    ダイナミックDNSもあります
    自宅サーバでもなんでもやってみることです
●   いまは情報が豊富になりました
●   言い訳ばっかりして動かない人、教えてもらわないとできな
    い人は、残念ながら向いてません
●   経験がない状態で考えたってどうせわかんないんだから、
    やってみよう!
            netmark.jp all rights reserved
情報源
●   twitter                                 ●   man
●   勉強会?交流会                                 ●   各種公式ドキュメント
●   blog/はてダ                                ●   RFC
                                            ●   ソースコード
●   ML
●   書籍
    ●   Software Design
    ●   WEB+DB Press
    ●   サーバ/インフラを支える技術
        (ISBN-10: 4774135666)

                          netmark.jp all rights reserved
将来性の话

    ※ひとつの形です
    ITSSで言うところの
      –   ITアーキテクト
      –   ITスペシャリスト
      –   アプリケーションスペシャリスト
      –   ソフトウェアデベロップメント
      –   ITサービスマネジメント
    をカバーして
●   地に足がついたアーキテクト になろう!
                  netmark.jp all rights reserved
たとえば(1):メルマガ配信サービス

    考慮すること????
●   性能             ???配信能力(チューニング、ブロック回避、実装方法)
●   キャパシティ         ???配信能力、負荷分散、データ量、、、
●   可用性            ???機器冗長化、機能冗長化、、、
●   セキュリティ
    ●   個人情報保護     ???ACL、層分離、、、
    ●   ウィルスチェック   ???実施タイミング?方法、、、
    ●   スパムチェック    ???実施タイミング?方法、、、
●   運用
    ●   メンテナンス     ???停止、バックアップ、、、
    ●   リラン        ???実現方法、実施方法、、、
                    netmark.jp all rights reserved
たとえば(1):メルマガ配信サービス

    考慮事項の具体例???
●   ブロック回避
    ●   逆引き設定、SPF、宛先精査?フィードバック、HELO/EHLO設定、、、
●   構成
    ●   複数拠点(別N/W)、IPアドレス数、、、
●   負荷分散
    ●   配信負荷分散、配信/管理サーバを分割、配信/管理NWを分割
    ●   配信設定の配布方法の検討
         –   rsync, NFS, Replication Slave,,,



                              netmark.jp all rights reserved
たとえば(2):メディアサイト
    考慮事項の具体例???ヒット時は通常の10~20倍のアクセス、広告収入モデル
●   性能
    ●   画面表示のレスポンスは快適にしたい
    ●   ページのデータ量を減らす?→生命線なので無理
    ●   画像の質を落とす?→落とせるものは落とす。落とせないものもある
    ●   広告?大きな画像はAJAXで非同期呼び出しにする?→広告は同期で!
    ●   広告は確実に配信したい→広告配信システムのチューニング
    ●   配信に特化したサーバ(web/広告)/CMSサーバ/広告配信サーバに分離
●   可用性
    ●   サイトダウンはできるだけ避けたい→ロードバランサを構築して利用
        もちろんOpenSource実装(Active - Hot Standby)
●   キャパシティ
    ●   アクセス数の増減がすさまじい???別回線にプチCDNを構築
                  netmark.jp all rights reserved
事例绍介(3):贰颁サイト
    考慮事項の具体例???セール時は通常の100倍のアクセス
●   性能
    ●   快適に買い物できるように!→Web/Appサーバを分離
●   可用性
    ●   サイトダウンはできるだけ避けたい
         –   ロードバランサ、複数回線利用、セッションレプリケーション
    ●   システムダウンはできるだけ避けたい
         –   DBはHA構成
●   キャパシティ
    ●   スケールアウト(Web/App/DB(Replication)を活用して水平分割
    ●   ファーミングなどの垂直分割も検討


                       netmark.jp all rights reserved
余談:インフラエンジニアから見たクラウド

●   面白い
●   オープン
    ●   Closed実装のクラウドは怖くて???
    ●   Openであるからこそ提案できる
        –   AWS - Eucalyptus, GAE - AppScale
●   発想の転換
    ●   既存の知識?ノウハウは流用できる部分もある(特にIaaS)
    ●   「仮想化」とは違う - 集約 <=> 発散
    ●   発想の異なる設計?管理(特にPaaS,SaaS)

                          netmark.jp all rights reserved
面白そうでしょ!?

なにか 不思議に思ったことなどあれば
   ぜひ聞いてみてください




    netmark.jp all rights reserved
おしまい



ご静聴いただきありがとうございました



    netmark.jp all rights reserved

More Related Content

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

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