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
old typeからのクラウドインフラ
Search
Sponsored
·
SiteGround - Reliable hosting with speed, security, and support you can count on.
→
kanayannet
May 07, 2022
Programming
430
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
old typeからのクラウドインフラ
kanayannet
May 07, 2022
More Decks by kanayannet
See All by kanayannet
リファクタリング ハーネス
kanayannet
1
120
厳密な定義
kanayannet
0
140
Mcp Training
kanayannet
0
260
MCP で「こいつ動くぞ」
kanayannet
0
190
無関心の谷
kanayannet
0
1.3k
生成AIの使いどころ
kanayannet
0
270
github copilot と 心理的安全性
kanayannet
0
300
FW と ライブラリ の考え方
kanayannet
0
280
TDDと今まで
kanayannet
0
750
Other Decks in Programming
See All in Programming
JPUG勉強会 OSSデータベースの内部構造を理解しよう(第2回)
oga5
0
260
Jetpack Compose メカニズム
skydoves
0
440
iOSDC Japan 2026 - Swiftで作って学ぼう!データベース自作入門
kaseken
2
170
Vibes Containers 〜AIで変わるコンテナ設計と運用〜
tkikuc
3
550
手動確認はもう限界 〜XCUITestでCustom URL Schemeの遷移を起動種別ごとに自動テストする〜 / Testing Custom URL Schemes with XCUITest
otouto
0
310
AGENTS.md Is Not Enough:Build Skills, Don't Download Them
lx_t
0
120
GraphRAGのKnowledge Graphを 直接!見る/View-GraphRAG's-KnowledgeGraph-directly!
tyumugi1113
1
340
マイコン向けの軽量Ruby「PicoRuby」で各種デバイスを制御するネイティブアプリの実現手法
bash0c7
0
420
thread_parallel_with_free-threaded_Python_and_NumPy.pdf
riku_sakamoto
0
350
20260914 AIエージェント時代のPlatform Engineering LLM基盤とプロダクトの責務境界線
kanfab1
7
2.1k
AI が書く Go コードの品質を劇的に向上させる Linter: “declscope”
mpyw
0
370
The Good Stuff, Not the Slop: Engineering High-Quality Android Apps with Modern AI Tooling
danybony
1
260
Featured
See All Featured
How STYLIGHT went responsive
nonsquared
100
6.3k
Winning Ecommerce Organic Search in an AI Era - #searchnstuff2025
aleyda
2
2.1k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
32
4.8k
Redefining SEO in the New Era of Traffic Generation
szymonslowik
1
420
The Organizational Zoo: Understanding Human Behavior Agility Through Metaphoric Constructive Conversations (based on the works of Arthur Shelley, Ph.D)
kimpetersen
PRO
0
460
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
38
3k
Statistics for Hackers
jakevdp
799
230k
Mozcon NYC 2025: Stop Losing SEO Traffic
samtorres
1
550
The #1 spot is gone: here's how to win anyway
tamaranovitovic
4
1.2k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.8k
エンジニアに許された特別な時間の終わり
watany
109
250k
BBQ
matthewcrist
89
10k
Transcript
Old type からの Old type からの クラウドインフラ クラウドインフラ Gunma.web #45
Gunma.web #45 @kanayannet @kanayannet
近況報告 ( 前座 ) 近況報告 ( 前座 ) 今更ですが... Ruby
技術者認定試験 Gold 合格
Gold 聖闘士になりました。 Gold 聖闘士になりました。
今のネタが伝わった方は世代がバレ ry.. 今のネタが伝わった方は世代がバレ ry..
前座はここまで 前座はここまで
今日の Agenda 今日の Agenda 前提 オンプレの冗長化・高可用性 クラウド・インフラだとどう便利? それぞれの特徴(AWS) 大事なこと まとめ
前提 前提
前提 前提 今回、VPS とクラウドの違いを厳密にはやらないです。 VPS も同じような?括りで話します。
前提 前提 AWS, GCP, Heroku など絶対主義者ではないです。 場合によってはオンプレでも良いと思う。 オンプレでも冗長化・耐障害性を考慮できる web サービスは回る(365
日) ダウンタイムをどれだけ少なくできるか? 頭の使い所は多い
前提 前提 規模が大きくなるほど、オンプレの方が単純な費用は安い? 人を育てる費用は別途考える必要がある 楽天, Hatena, Pixiv さんはオンプレクラウドと言っている 費用が安いなど、どうしてもフルクラウドできない
オンプレの オンプレの 冗長化・高可用性 冗長化・高可用性
知ってますか?この仕組みを 知ってますか?この仕組みを
DRBD Pacemaker VRRP LVS
複数のサーバ間のHDD をリアルタイムに レプリケーション 死活監視 -> 何かをキックする 仮想IP L4 の 負荷分散装置
オンプレだとこれらを意識して オンプレだとこれらを意識して 365 日24 時間動き続ける仕組みを作る訳ですね。 発電機や無停電装置(UPS) 力率計算( 突入電流) etc...
人によってですが ... 人によってですが ... 覚えたい 純粋なコンピュータサイエンスへの興味 大変だ( 汗) 機械・ハードウェアの部分
当然ですが ... 当然ですが ...
育てる側に立つと ... 育てる側に立つと ... 引き継ぎかつ受け継がせる事は困難
これらを熟る人は尊敬できます 一方で中々できる人( 特に継続できる人) が 中々いない現状もある
クラウド・インフラだと クラウド・インフラだと どう便利? どう便利?
オンプレ高可用性の専門知識 オンプレ高可用性の専門知識 「それほど」要らないです。
「それほど」? 「それほど」? 敢えてこう表現しています。 「意識しなくて良い」とは違うよ 例 ec2 1 台 立てれば何もしなくて良い そんな訳ないよね。
高可用性 高可用性 何か障害があっても、システムの停止時間をなるべく少なく することを指す。
どうすれば維持できる? どうすれば維持できる?
AWS での例 AWS での例 負荷分散 ELB 負荷分散する対象のサーバはprivate なネットワーク環境が欲 しい VPC
落ちた時に切り替わるように CloudWatch アラーム(ec2) ECS( コンテナ系) の自動復旧 負荷増えて足りなくなった Auto Scaling レプリケーションやダウンをほぼしない系の仕組
RDS, S3, etc...
あれ? あれ? 気づいた人いますか?
DRBD Pacemaker VRRP LVS
日本語化リプレイ 日本語化リプレイ 複数のサーバ間のHDD をリアルタイムに レプリケーション 死活監視 -> 何かをキックする 仮想IP L4
の負荷分散装置
多少にニュアンスや範囲や解釈の違い 多少にニュアンスや範囲や解釈の違い はあるが ... はあるが ...
意識の仕方が変わっただけ 意識の仕方が変わっただけ
ただし ... 重要 ただし ... 重要
ハード系 ハード系 OS(Linux 系) とハード機器の相性考えなくて良い middle ware の構築と↑ とのバランスを考えなくて良い ましてや発電機なんてもってのほか
冬場は加湿も必要なのよ 冬場は加湿も必要なのよ
静電気トラップ 静電気トラップ
本編に戻ります m(__)m 本編に戻ります m(__)m
それぞれの特徴 (AWS) それぞれの特徴 (AWS)
Lambda Lambda
Lambda Lambda イベントの種類が豊富 S3, API Gateway, CloudWatch ...etc 使う用途が「これだ!」と解りきっているものは定義しやす い
例: S3 に写真をアップしたら、縮小版サムネイルも自動作 成 キックされる回数が読めてるとやり易い 無料枠に入る? リクエスト回数 && メモリ の従量課金
逆に ... 逆に ... まだ要求される仕様がまとまりきってない時はやりずらいか な? 結果: キックされる回数、実行時間、メモリともに食いやす い とんでもない請求額
これだったら ec2 の daemon 起動の方が良かった..etc
EC2 EC2
EC2 EC2 自由度が高い OS と スペックを選んで中身は自分( 達) で組み上げる VPS 相当
-> 違いがあるとすれば、他の cloud service と連携 しやすい部分かな? 落ちた時のデータの保証的なものはvps は自己責任がほと んどですが... 実際はRAID 構成を組んでるなど「保証はないけど欠損は目 立たない」かな?
EC2 EC2 どんな時に使うと便利そう?
EC2 EC2 色々模索中の場合 色々模索中の場合 要求仕様すらよく解ってない時 とりあえず進めながら形にしながら... 解らない部分を解るようにしながら
不確実性のコーン 不確実性のコーン by itmedia: https://blogs.itmedia.co.jp/hideshibamoto/2013/01/post-7a0e.html
形にしないと 形にしないと エンジニア以外の人には伝わらないよね? あるある話 この前提で色んなcloud サービスを組み込んでしまうと... over spec だったり そのcloud
サービスに「縛られたり」 考え方 設計思想 IF
ECS ECS 実行環境をDockerfile で表現できる ec2 ほどの自由度はないかも? だが、リリース前には「言葉で定義可能」なものになるは ず つまり Dockerfile
に出来るよね? 何をもって「落ちた」とするか?が明確
以下の例 以下の例 Dockerfile ./entrypoint.sh # ..... ENTRYPOINT ["./entrypoint.sh"] # ....
bundle exec rails s -e production
rails が落ちたらコンテナ落ちた rails が落ちたらコンテナ落ちた と見なすことが容易に可能 ECS は自動でコンテナを再立ち上げ出来る
大事なこと 大事なこと
cloud だからって ... cloud だからって ... 高可用性、耐障害性を意識しなくて良いわけじ 高可用性、耐障害性を意識しなくて良いわけじ ゃない ゃない
ところで ところで
これって何? これって何? 高可用性 耐障害性
今日初めて知った 今日初めて知った という方は、是非お持ち帰りいただければと...
なぜか? なぜか? 覚えるってなに? 覚えるってなに?
知識として知っているだけ 「既に試して」身につけている状態
全然違う 全然違う
自分で調べて 自分で実行して 自分で検証して Try and Error 繰り返して...
まとめ まとめ Cloud インフラは確かに効果はある ハード面、設備面は気にしなくて良い 全く冗長化、高可用性、耐障害性を気にしなくて良いわけじ ゃない 適切な構成( アーキテクチャ) は必要
初めからがっつりと cloud アーキテクト組みすぎると... 後が大変( な場合もある) 不確実なものとの向き合い方 -> 重要
何が適切か?進めながら「最適解」を探す旅 Try and Error 反復練習し手応えを掴む感覚に近いかも?
あくまで自分の経験談ですが あくまで自分の経験談ですが
画像は著作権の都合上 画像は著作権の都合上 資料公開時には ...ry 資料公開時には ...ry
ご清聴 ご清聴 ありがとうございました! ありがとうございました!