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
800
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
データマネジメントのトレードオフに立ち向かう
ikkimiyazaki
6
1.2k
AIエージェント入門
minorun365
PRO
20
11k
ディスプレイ広告(Yahoo!広告・LINE広告)におけるバックエンド開発
lycorptech_jp
PRO
0
230
ウォンテッドリーのデータパイプラインを支える ETL のための analytics, rds-exporter / analytics, rds-exporter for ETL to support Wantedly's data pipeline
unblee
0
110
Potential EM 制度を始めた理由、そして2年後にやめた理由 - EMConf JP 2025
hoyo
2
1.8k
Oracle Database Technology Night #87-1 : Exadata Database Service on Exascale Infrastructure(ExaDB-XS)サービス詳細
oracle4engineer
PRO
1
100
OSS構成管理ツールCMDBuildを使ったAWSリソース管理の自動化
satorufunai
0
480
EMConf JP 2025 懇親会LT / EMConf JP 2025 social gathering
sugamasao
2
180
AIエージェント時代のエンジニアになろう #jawsug #jawsdays2025 / 20250301 Agentic AI Engineering
yoshidashingo
4
330
ESXi で仮想化した ARM 環境で LLM を動作させてみるぞ
unnowataru
0
150
エンジニアが加速させるプロダクトディスカバリー 〜最速で価値ある機能を見つける方法〜 / product discovery accelerated by engineers
rince
4
540
RemoveだらけのPHPUnit 12に備えよう
cocoeyes02
0
170
Featured
See All Featured
How to train your dragon (web standard)
notwaldorf
91
5.9k
Automating Front-end Workflow
addyosmani
1368
200k
Build your cross-platform service in a week with App Engine
jlugia
229
18k
Why You Should Never Use an ORM
jnunemaker
PRO
55
9.2k
Stop Working from a Prison Cell
hatefulcrawdad
267
20k
What’s in a name? Adding method to the madness
productmarketing
PRO
22
3.3k
Reflections from 52 weeks, 52 projects
jeffersonlam
348
20k
Faster Mobile Websites
deanohume
306
31k
The Art of Programming - Codeland 2020
erikaheidi
53
13k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
29
1k
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
StorybookのUI Testing Handbookを読んだ
zakiyama
28
5.5k
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 おしまい ご静聴いただきありがとうございました