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

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

netmark.jp all rights reserved 守備範囲の実際のトコロ(実務) ● 設計・・・機能分割、ソフトウェア、ミドルウェア、サーバ、ネットワーク、ネットワーク、相互連携 ● 構築・・・機器設定、OSセットアップ、ミドルウェア設定、ソフトウェアチューニング、相互連携設定 ● 運用・・・非定型・非定例作業　※定例・定形作業は基本的に自動化 ● 監視・・・システムがビジネス要求を満たしていることをチェック。ハード/ソフト/サービスの状況を逐次確認し、障害・異常発見時には対応実施 ● 管理・・・システム設定変更、セキュリティ設定・維持、バックアップ ● 提案・コンサルティング・・・現在のシステムをよくわかっている立場から、状況改善をご提案 ● 障害対応コンサルティング・・・現在抱えているトラブルを解消・回避するお手伝い

Slide 8

Slide 8 text

netmark.jp all rights reserved 守備範囲の実際のトコロ(技術) ● ネットワーク系 ● L1～L7 ● HTTP(S)、DNS、メール、PKIのしくみ・・・ ● サーバ系 ● 電源 ● ハードウェア, OS ● ミドルウェア ● 特徴,設定,チューニング... ● アプリケーション ● セッションパーシステンス,O/R, キューイング... ● Railsの特徴、 symfony、Strutsの特徴... ● テクノロジー ● RDB,Key/Value ● アーキテクチャ ● 高可用性設計と実現 ● 負荷分散設計と実現 ● セキュリティ ● クラウド ● 運用設計 ● 運用作業 ● メンテナンス性 ● バックアップ・係数取得 ● HTML,CSS,AJAX... ● SEO,集合知...

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

netmark.jp all rights reserved どうやったらインフラエンジニアになれるの？１．始めること！自ら動くこと！２．楽しむこと！ ● 実装は中古PCとLANで始められますダイナミックDNSもあります自宅サーバでもなんでもやってみることです ● いまは情報が豊富になりました ● 言い訳ばっかりして動かない人、教えてもらわないとできない人は、残念ながら向いてません ● 経験がない状態で考えたってどうせわかんないんだから、やってみよう！

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

netmark.jp all rights reserved たとえば(1):メルマガ配信サービス考慮事項の具体例・・・ ● ブロック回避 ● 逆引き設定、SPF、宛先精査・フィードバック、HELO/EHLO設定、、、 ● 構成 ● 複数拠点(別N/W)、IPアドレス数、、、 ● 負荷分散 ● 配信負荷分散、配信/管理サーバを分割、配信/管理NWを分割 ● 配信設定の配布方法の検討 – rsync, NFS, Replication Slave,,,

Slide 20

Slide 20 text

netmark.jp all rights reserved たとえば(2):メディアサイト考慮事項の具体例・・・ヒット時は通常の10～20倍のアクセス、広告収入モデル ● 性能 ● 画面表示のレスポンスは快適にしたい ● ページのデータ量を減らす？→生命線なので無理 ● 画像の質を落とす？→落とせるものは落とす。落とせないものもある ● 広告・大きな画像はAJAXで非同期呼び出しにする？→広告は同期で！ ● 広告は確実に配信したい→広告配信システムのチューニング ● 配信に特化したサーバ(web/広告)/CMSサーバ/広告配信サーバに分離 ● 可用性 ● サイトダウンはできるだけ避けたい→ロードバランサを構築して利用もちろんOpenSource実装(Active - Hot Standby) ● キャパシティ ● アクセス数の増減がすさまじい・・・別回線にプチCDNを構築

Slide 21

Slide 21 text

netmark.jp all rights reserved 事例紹介(3):ECサイト考慮事項の具体例・・・セール時は通常の100倍のアクセス ● 性能 ● 快適に買い物できるように！→Web/Appサーバを分離 ● 可用性 ● サイトダウンはできるだけ避けたい – ロードバランサ、複数回線利用、セッションレプリケーション ● システムダウンはできるだけ避けたい – DBはHA構成 ● キャパシティ ● スケールアウト(Web/App/DB(Replication)を活用して水平分割 ● ファーミングなどの垂直分割も検討

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

Slide 24

Slide 24 text