Mais conteúdo relacionado
Mais de Toshiaki Baba (13)
インフラエンジニアになろう!
- 2. 自己紹介
● 馬場俊彰(ばばとしあき)
– id:netmarkjp
– blog: http://netmark.jp/
– twitter: toshiak_netmark
● インフラエンジニア
● 情報処理技術者:TE-DB
● Javaプログラマーをしてたこともあります
● 株式会社ハートビーツのCTO
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. ITの何が楽しいの?
夢があるよね!
● 自分の力でたくさんの人の心を動かせる!
● 自分の力でたくさんの人を幸せにできる!
● 世界を動かすことだってできる!
● 学ぶ・創る がずっとできる!
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
- 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):ECサイト
考慮事項の具体例・・・セール時は通常の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