Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
インフラエンジニアになろう!
Search
Toshiaki Baba
June 06, 2009
Technology
0
30
インフラエンジニアになろう!
2009.6.6にAIIT(産業技術大学院大学)にて、学生会主催の勉強会で話した内容です
https://www.slideshare.net/toshiak_netmark/ss-1542208
Toshiaki Baba
June 06, 2009
Tweet
Share
More Decks by Toshiaki Baba
See All by Toshiaki Baba
SREsのためのSRE定着ガイド
netmarkjp
12
8.4k
SREこのへんで苦戦しがちじゃないですか?
netmarkjp
13
6.4k
技術書を活用してほしい!
netmarkjp
0
510
しつこくじわじわパフォーマンスチューニング
netmarkjp
1
1.2k
現場がさき、 プラクティスがあと、 原則はだいじに
netmarkjp
4
2.9k
ばばさんは、なぜ本を書くの?という話
netmarkjp
0
810
SRE≠インフラなんだけどもう誤解されちゃってる から、DevOps新実装として Site Production Engineering はいかがでしょう?
netmarkjp
2
2.1k
非ITの事業会社にSREと言わずにSREを持ち込んだ
netmarkjp
16
30k
変化の激しいWebの世界でコンスタントに局面局面で勝つ方法論「OODAループ」
netmarkjp
0
2k
Other Decks in Technology
See All in Technology
Autonomous Database Serverless 技術詳細 / adb-s_technical_detail_jp
oracle4engineer
PRO
17
45k
実は強い 非ViTな画像認識モデル
tattaka
3
1.3k
サイト信頼性エンジニアリングとAmazon Web Services / SRE and AWS
ymotongpoo
7
1.6k
クラウド関連のインシデントケースを収集して見えてきたもの
lhazy
8
1.1k
エンジニアリング価値を黒字化する バリューベース戦略を用いた 技術戦略策定の道のり
kzkmaeda
6
2.7k
Perlの生きのこり - エンジニアがこの先生きのこるためのカンファレンス2025
kfly8
2
270
データベースの負荷を紐解く/untangle-the-database-load
emiki
2
520
AIエージェント時代のエンジニアになろう #jawsug #jawsdays2025 / 20250301 Agentic AI Engineering
yoshidashingo
8
3.7k
データエンジニアリング領域におけるDuckDBのユースケース
chanyou0311
9
2.2k
依存パッケージの更新はコツコツが勝つコツ! / phpcon_nagoya2025
blue_goheimochi
3
220
手を動かしてレベルアップしよう!
maruto
0
220
入門 PEAK Threat Hunting @SECCON
odorusatoshi
0
160
Featured
See All Featured
The Power of CSS Pseudo Elements
geoffreycrofte
75
5.5k
Being A Developer After 40
akosma
89
590k
Statistics for Hackers
jakevdp
797
220k
Designing on Purpose - Digital PM Summit 2013
jponch
117
7.1k
Fantastic passwords and where to find them - at NoRuKo
philnash
51
3k
The World Runs on Bad Software
bkeepers
PRO
67
11k
Building Applications with DynamoDB
mza
93
6.2k
Adopting Sorbet at Scale
ufuk
74
9.2k
Building a Modern Day E-commerce SEO Strategy
aleyda
38
7.1k
Docker and Python
trallard
44
3.3k
It's Worth the Effort
3n
184
28k
Writing Fast Ruby
sferik
628
61k
Transcript
netmark.jp all rights reserved インフラエンジニアになろう!
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 •
HTTP(S)、DNS、メール、PKIの しくみ・・・ • サーバ系 • 電源 • ハードウェア, OS • ミドルウェア • 特徴,設定,チューニング... • アプリケーション • セッションパーシステンス,O/R, キューイング... • Railsの特徴、 symfony、Strutsの特徴... • テクノロジー • RDB,Key/Value • アーキテクチャ • 高可用性設計と実現 • 負荷分散設計と実現 • セキュリティ • クラウド • 運用設計 • 運用作業 • メンテナンス性 • バックアップ・係数取得 • HTML,CSS,AJAX... • SEO,集合知...
netmark.jp all rights reserved 何が楽しいの? • インフラエンジニア って何が楽しいんでしょう? • 代表的な例。。。たとえばプログラマーの場合 •
システムを完成させて納品したときの達成感 • システムがC/Oしたときのドキドキ • お客さんからお礼を言われたときの感動 • などなど・・・ • というか・・・・・・ITって何が楽しいんでしょう!?
netmark.jp all rights reserved ITの何が楽しいの? 夢があるよね! • 自分の力でたくさんの人の心を動かせる! • 自分の力でたくさんの人を幸せにできる!
• 世界を動かすことだってできる! • 学ぶ・創る がずっとできる!
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 • 勉強会・交流会 •
blog/はてダ • ML • 書籍 • Software Design • WEB+DB Press • サーバ/インフラを支える技術 (ISBN-10: 4774135666) • man • 各種公式ドキュメント • RFC • ソースコード
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):ECサイト 考慮事項の具体例・・・セール時は通常の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 おしまい ご静聴いただきありがとうございました