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
t.kizawa
July 27, 2026
Technology
110
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
歴史から理解するクラウドインフラのしくみ
2026/7/27開催
ちゃんこね #1
【アプリ屋、インフラ屋あつまれ!】フルスタックエンジニアを目指す会
t.kizawa
July 27, 2026
More Decks by t.kizawa
See All by t.kizawa
Amazon CloudFrontにおけるAIボットアクセス制御のポイント
kizawa2020
5
380
SORACOM MCP Serverを使ってみよう
kizawa2020
1
87
Amazon Novaをはじめよう! 画像・動画生成ハンズオンの紹介
kizawa2020
0
420
Introduction of use cases using IoT buttons in Japan
kizawa2020
1
670
個人検証アカウントでも最低限設定したいプラクティス
kizawa2020
3
2.9k
IoTボタン開発のススメ
kizawa2020
0
570
re:Inventで発表があったIoT事例の紹介と考察
kizawa2020
0
430
SORACOM User Groupのご紹介
kizawa2020
0
2.2k
SORACOM にて提供されている主なIoTデバイスのご紹介
kizawa2020
0
370
Other Decks in Technology
See All in Technology
PHPで作って学ぶリアルタイム音声対話AIとWebSocket入門 by ムナカタ
munakata
0
150
「待ち時間」の消滅と「自我消耗」の加速:生成AI時代のエンジニアを救うメンタル・リソース管理
poropinai1966
0
120
キャリアLT会#3
beli68
2
260
変更し続けられるシステムをどう保つか — AI時代のSSoTという設計原則
kawauso
1
1.2k
どこまでAIに任せるか 〜確率論と決定論の境界決定〜
shukob
0
510
2026年のソフトウェア開発を考える(2026/07版) / Agentic Software Engineering 2026-07 Findy Edition
twada
PRO
28
14k
VPCセキュリティ対応の最新事情
nagisa53
1
320
SoccerMaster: A Vision Foundation Model for Soccer Understanding
kzykmyzw
0
180
Playwright × AI Agent でE2Eテストはどう変わるか AI駆動テストの可能性と実用検証の結果
taiga7543
2
870
AI研修(Day1)【MIXI 26新卒技術研修】
mixi_engineers
PRO
1
470
既存repo / AIとのやり取りから、おれのハーネスエンジニアリングの現状と課題を見てもらった
tsukasagr
1
100
探索・可視化・自動化を一本化 Amazon Quickでデータ活用スピードを上げる方法
koheiyoshikawa
0
190
Featured
See All Featured
The agentic SEO stack - context over prompts
schlessera
0
850
Prompt Engineering for Job Search
mfonobong
0
380
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
123
22k
So, you think you're a good person
axbom
PRO
2
2.1k
SEO Brein meetup: CTRL+C is not how to scale international SEO
lindahogenes
1
2.8k
SEOcharity - Dark patterns in SEO and UX: How to avoid them and build a more ethical web
sarafernandez
0
220
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.8k
Into the Great Unknown - MozCon
thekraken
41
2.6k
Automating Front-end Workflow
addyosmani
1370
210k
Art, The Web, and Tiny UX
lynnandtonic
304
22k
Mind Mapping
helmedeiros
PRO
1
290
A Guide to Academic Writing Using Generative AI - A Workshop
ks91
PRO
1
360
Transcript
【アプリ屋、インフラ屋あつまれ!】 フルスタックエンジニアを目指す会 #1 歴史から理解するクラウドインフラのしくみ 2026年7月27日 Tomotaka Kizawa ( kizawa2020 )
▪ 自己紹介 名前 : 木澤 朋隆 (きざわ ともたか) 所属 :
とあるSIer企業 主な表彰: AWS Ambassador (2021~) Japan AWS Top Engineer (2022~) Japan AWS All Certifications Engineer (2022~) AWS Community Builder (2023~) SORACOM MVC 2022 第4740号 Page.2
▪ 私の経歴 2000~2003年 客先常駐(サーバ運用構築・ユーザサポート) 「インフラができる」と認知される 2004~2015年 アプリケーション開発部署内のインフラチームリーダー (プリセールス~構築~保守) ※オンプレもクラウドも、顧客要件次第で何でも・・・ 社内公募で異動
2016~2019年 自社クラウドサービスの次世代基盤開発リーダー 2020年~ クラウド全般のプリセールス ⇒ マーケティング/プロモーション担当 Page.3
▪ 本日の主旨 クラウドは魔法ではない 現在はクラウドを用いるのが当たり前になりました。 そして、それをベースとした開発スタイルも当たり前となりました。 クラウドは、長年積み重ねてきた、ITインフラの進化の結果だったりします。 クラウドを使う際や、クラウドで障害が発生した際も、中身の仕組みを把握すること で、より理解が深めることができるはずです。 クラウドは、従来の物理インフラを、 そのまま仮想世界で実現できるもの
ITの民主化 Page.4
ITインフラの歴史 Page.5
▪ 物理専用サーバの時代(~1990年代) ~1980年代 : 汎用機(メインフレーム)の時代 1990年代 : ダウンサイジング(UNIXサーバへの移行) Web/AP、DB、バックアップ等、機能ごとに物理サーバを設置 PC
ファイヤウォール キッティング・ラッキング・ケーブリング、 OS・ミドルウェア導入/設定に時間が掛かる (システム規模にも依りますが、1週~3ヶ月程度) ルーター/LB スイッチ ポイント 各社専用のUNIXマシン、1台でも百万円程度から システム全体で数千万円のイニシャルコスト 機器の調達には数ヶ月かかる サイジングに余裕を持つ必要がある 一度購入した機器は数年間使い続ける必要がある メインフレーム UNIXサーバ Windows サーバ Page.6
▪ Linuxの登場 コモディティ化の第一歩 1991年、当時フィンランド在住の学生、リーナス・トーバルズ氏が 自身のPCで動作するUNIX系OSをオープンソースで公開したのが始まり。 1990年代においては、商用UNIXと比べて安定性で劣ることから UNIXライクなOSを個人のPCにインストールして遊べる 「おもちゃ」としての扱いだった。 インストールを容易にしたLinuxディストリビューションが各社から登場。 群雄割拠の時代を経て、2002年にRedHat社から、商用レベルの長期サポートを謳った
RedHat Enterprise Linuxが登場し急激に転換が進んだ。 サーバインフラにおいて 専用ハードウェアが必要でなくなり、 Intel x86アーキテクチャに統一された ことが大きい。 Page.7
▪ IAサーバ仮想化の革命(2000年代) 仮想化技術の起源(1960年代~) 歴史は古く、非常に高額なメインフレームを複数人・システムで分割する技術として始まる ダウンサイジングの結果(1990年代~2020年代前半) 安価なIAサーバとLinux/Windowsが普及したが、1ハードウェア 1OSが常識のため サーバ機器が乱立。CPU/メモリリソースの利用効率が悪い状態に陥った。 VMwareの登場 1999年にVMware
WorkStationを発表。当初は「開発者のテスト用・検証用(おもちゃ)」 商用レベルでの利用へ 2001年にハイパーバイザー ESX Server がリリース 2006年に VMware Infrastructure 3(vSphere3)が登場し本番環境への導入が進む。 オープンソースのハイパーバイザーである XenやKVMも追従して登場 Page.8
▪ (補足) vSphere主要技術 vMotion 無停止で仮想サーバを 別ホストに移動(手動) VMware HA 物理サーバ障害時に 仮想サーバを自動で
別ホストに移動 VMware DRS リソース利用状況を 踏まえ仮想サーバ を自動的に再配置 VMware Consolidated Backup 仮想サーバ丸ごと 増分バックアップ Page.9
▪ VPSサービスの登場 仮想化技術を用いた仮想サーバホスティング(VPS)のサービスが各社から提供開始される。 非常に安価にサーバを借りられるため便利。 現在でも提供されている各社サービス Amazon Lightsail (AWS) さくらのVPS(さくらインターネット) ConoHa(GMOインターネット)
Amazon Lightsail 補足)Classic EC2 AWS(EC2)サービスにおいても、VPC登場(2009年)前の、 いわゆるClassic EC2はVPSのサービス言える。 EC2インスタンス1台1台にパブリックIPが付与されており、 インスタンス間の通信はセキュリティグループで制御する仕様だった。 2022年8月にサービス終了済。 Page.10
▪ SDxの波が到来 サーバー機器だけでなく、システムを構成するネットワークやストレージにおいても ソフトウェア化のトレンドが発生。 SDN SDS (Software Defined Network) (Software
Defined Storage) ルーターやスイッチ、ロードバランサーなど、 物理的なネットワーク機器もソフトウェアで実装 高価な専用ストレージを、汎用サーバー上のソフ トウェアで実装するアプローチ (例) (例) ・ VMware NSX ・VMware vSAN ・ VyOS ・Ceph ・OpenZFS NW機器・ストレージも Intel x86アーキテクチャに統一 Page.11
これで全てが 「ソフトウェア」 になった サーバー、ネットワーク、ストレージ 物理的な制約を完全に排除 Page.12
クラウド登場と、その後の話 Page.13
▪ クラウド(IaaS)の登場 (2008年頃〜 SDxで抽象化された巨大なデータセンターを、 画面やAPIを通じて、誰でも数分で従量課金で利用可能に。 それがクラウドの正体。 これまでの仮想化技術の巨大な集合体を従量課金で 貸し出しているだけ。 ポイント イニシャルコストがかからない
すぐに利用することができる 柔軟にリソース調整できるので厳格なサイジング不要 すぐに止めることもできる 最新技術もすぐに活用することができる (ITの民主化) 資本が無くてもアイディア1つでイノベーションが起こせる Page.14
▪ (補足①) クラウドコンピューティングの定義 米国国立標準技術研究所(NIST)による定義 クラウドコンピューティングは、共用の構成可能なコンピューティングリソース(※)の集積に、 どこからでも、簡便に、必要に応じて、ネットワーク経由でアクセスすることを可能とするモデル。 ※ ネットワーク、サーバー、ストレージ、アプリケーション、サービス 基本的な特徴 オンデマンド/セルフサービス
幅広いネットワークアクセス リソースの共用 スピーディな拡張性 サービスが計測可能であること Page.15
▪ (補足②) クラウド10の理由 AWSが提供する 「AWSのクラウドが選ばれる10の理由」 ページが秀逸 https://aws.amazon.com/jp/aws-ten-reasons/ なぜクラウドを使うと良いのか? どのようなシステム・要件に適合しやすいのか、、など 定期的に振り返るとよい。
Page.16
▪ インフラをコードで書く時代へ(IaC) インフラがAPI化(ソフトウェア化)されたことで、インフラ設定をコードとして記述可能に。 AnsibleやChefから始まり、現在はTerraformやAWS CDK等が主流に。 従来のインフラ構築 構築手法 スピード 品質・精度 履歴・管理
テスト 手順書/パラメータシート(Excel等)を見ながら、画面操作やコマンドを手打ち サーバー台数に比例して作業時間が増加(数時間〜数日) 人の手による作業のため、設定漏れなどのヒューマンエラーが発生しやすい 「誰がいつ変更したか」が不明確になり、構成図と実態がズレていく 実際に構築を終えてからでないと、正しく動くか確認できない IaCを用いた構築 構築手法 スピード 品質・精度 履歴・管理 テスト インフラ構成をコード(テキスト)で定義し、ツールで自動構築 1台でも100台でも、コードを実行すれば数分で一括構築 誰が実行してもコード通りに全く同じ環境が作られるため(冪等性)、ミスを排除 Git等でバージョン管理でき、変更履歴の追跡や過去の状態への切り戻しが容易 実行前にコードのレビューやエラーチェック(静的解析)ができ、事前にバグを防げる Page.17
▪ コンテナとサーバレスの時代へ(2014年頃〜) インフラがAPI化された後のトレンドとして OSの管理が開発スピードを阻害することに Docker(2013)によるコンテナ技術、そして AWS Lambda(2014)等のサーバーレスの登場により インフラを意識せずにコードだけを実行可能に。 DevOps 高速開発の必須要件へ
Page.18
まとめ Page.19
▪ まとめ 歴史を理解することで クラウドの仕組みが見えるようになる アーキテクチャ設計やトラブルシューティングにおいて、 物理的に何が起きているかを想像できる力が、 エンジニアとしての差を生みます。 Page.20