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
54
インフラエンジニアになろう!
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
Forkewell Library 103 『バックエンドエンジニアのためのインフラ・クラウド大全』を通じたエンジニアとしての地力獲得活動のススメ
netmarkjp
9
3.6k
AI時代にも変わらぬ価値を発揮したい: インフラ・クラウドを切り口にユーザー価値と非機能要件に向き合ってエンジニアとしての地力を培う
netmarkjp
0
430
著者による『バックエンドエンジニアのためのインフラ・クラウド大全』120%活用術
netmarkjp
1
920
SREsのためのSRE定着ガイド
netmarkjp
12
9.4k
SREこのへんで苦戦しがちじゃないですか?
netmarkjp
13
6.8k
技術書を活用してほしい!
netmarkjp
0
600
しつこくじわじわパフォーマンスチューニング
netmarkjp
1
1.4k
現場がさき、 プラクティスがあと、 原則はだいじに
netmarkjp
4
3.3k
ばばさんは、なぜ本を書くの?という話
netmarkjp
0
1.1k
Other Decks in Technology
See All in Technology
slog.Handlerのよくある実装ミス
sakiengineer
4
480
5分でカオスエンジニアリングを分かった気になろう
pandayumi
0
260
Generative AI Japan 第一回生成AI実践研究会「AI駆動開発の現在地──ブレイクスルーの鍵を握るのはデータ領域」
shisyu_gaku
0
330
「何となくテストする」を卒業するためにプロダクトが動く仕組みを理解しよう
kawabeaver
0
440
会社紹介資料 / Sansan Company Profile
sansan33
PRO
6
380k
「どこから読む?」コードとカルチャーに最速で馴染むための実践ガイド
zozotech
PRO
0
570
[ JAWS-UG 東京 CommunityBuilders Night #2 ]SlackとAmazon Q Developerで 運用効率化を模索する
sh_fk2
3
460
Apache Spark もくもく会
taka_aki
0
140
AWSで始める実践Dagster入門
kitagawaz
1
750
職種の壁を溶かして開発サイクルを高速に回す~情報透明性と職種越境から考えるAIフレンドリーな職種間連携~
daitasu
0
190
エンジニアが主導できる組織づくり ー 製品と事業を進化させる体制へのシフト
ueokande
1
110
2025/09/16 仕様駆動開発とAI-DLCが導くAI駆動開発の新フェーズ
masahiro_okamura
0
140
Featured
See All Featured
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
33
2.4k
Being A Developer After 40
akosma
90
590k
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
8
530
For a Future-Friendly Web
brad_frost
180
9.9k
Making Projects Easy
brettharned
117
6.4k
Embracing the Ebb and Flow
colly
87
4.8k
The Straight Up "How To Draw Better" Workshop
denniskardys
236
140k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
26
3k
Measuring & Analyzing Core Web Vitals
bluesmoon
9
580
A Tale of Four Properties
chriscoyier
160
23k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
52
5.6k
BBQ
matthewcrist
89
9.8k
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 おしまい ご静聴いただきありがとうございました