Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
歴史から理解するクラウドインフラのしくみ
Search
t.kizawa
July 27, 2026
Technology
250
1
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
国境を越えて大ウケ!「会議脱出ボタン」LTの裏側とスライドの哲学
kizawa2020
1
94
「面白い!」を信じ抜け。激動の時代を貫く、オンリーワン・エンジニアの条件
kizawa2020
2
1.1k
Amazon CloudFrontにおけるAIボットアクセス制御のポイント
kizawa2020
5
430
SORACOM MCP Serverを使ってみよう
kizawa2020
1
98
Amazon Novaをはじめよう! 画像・動画生成ハンズオンの紹介
kizawa2020
0
440
Introduction of use cases using IoT buttons in Japan
kizawa2020
1
720
個人検証アカウントでも最低限設定したいプラクティス
kizawa2020
3
3k
IoTボタン開発のススメ
kizawa2020
0
660
re:Inventで発表があったIoT事例の紹介と考察
kizawa2020
0
450
Other Decks in Technology
See All in Technology
AI時代に顧客へ最速で価値を 届けるための試行錯誤 〜「AI × マネジメント」領域におけるmentoのケース〜
posterkeisuke
0
120
AIネイティブプロダクトで顧客価値を最大化するプロダクトエンジニアとFDEの協働
righttouch
PRO
0
240
『止めない』を設計する — 制約の中で、事業の根幹を支える判断
hiroyaterui
0
270
Snowflakeで実現する全社横断の顧客の声(VOC)分析・活用基盤@Snowflake World Tour Tokyo 2026
yuto16
0
200
なぜSRE・セキュリティは評価されないのか?守りの組織を事業成長エンジンに変えた実践
cscengineer
PRO
3
2.5k
Sigmaで作る業務アプリ
kazushiro_honma
0
120
Microsoft 365 Copilot chat -tekoälypalvelun tietosuojaongelmat
hponka
0
740
新機種発売前に見直そう!端末移行で再ログインが要るアプリ・要らないアプリは何が違うのか 〜シームレスに再開できる設計と実装〜
zozotech
PRO
0
120
20260906 「AWS運用入門」著者が教える、運用業務への生成AI活用入門
masaruogura
0
260
range over func 2年間の軌跡 Issue #56413 はGoのエコシステムをどう変えたか
ryujicre8ive
0
110
Snowflakeのコスト最適化を支えるアーキテクチャ設計
ktatsuya
1
1.5k
synctest時代のhttptest Go 1.27で変わるHTTPサーバテストの裏側 / go conference2026 synctest and httptest
budougumi0617
1
2.7k
Featured
See All Featured
StorybookのUI Testing Handbookを読んだ
zakiyama
31
6.9k
Building an army of robots
kneath
306
46k
Mobile First: as difficult as doing things right
swwweet
225
10k
Dominate Local Search Results - an insider guide to GBP, reviews, and Local SEO
greggifford
PRO
0
330
How to train your dragon (web standard)
notwaldorf
97
6.8k
Ecommerce SEO: The Keys for Success Now & Beyond - #SERPConf2024
aleyda
1
2.1k
How to Build an AI Search Optimization Roadmap - Criteria and Steps to Take #SEOIRL
aleyda
1
2.2k
The Director’s Chair: Orchestrating AI for Truly Effective Learning
tmiket
1
300
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
31
3.4k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
27k
<Decoding/> the Language of Devs - We Love SEO 2024
nikkihalliwell
1
320
Design of three-dimensional binary manipulators for pick-and-place task avoiding obstacles (IECON2024)
konakalab
0
590
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