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
システム設計勉強会1回
Search
Sponsored
·
Your Podcast. Everywhere. Effortlessly.
Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
→
Sora-T
April 01, 2026
Technology
6
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
システム設計勉強会1回
システム設計勉強会1回
Sora-T
April 01, 2026
More Decks by Sora-T
See All by Sora-T
システム設計勉強会2回
soratogo331
0
7
LT会ネタ AI時代に対する自分の思考
soratogo331
0
52
Other Decks in Technology
See All in Technology
AI時代のPlaywright活用(システムテストを自動化する ー 実行エンジンにPla ywrightを選んだ理由)
ynisqa1988
0
130
SREとQA 二人三脚で進めるSLO運用/sre-qa-slo
sugitak
0
820
SoccerMaster: A Vision Foundation Model for Soccer Understanding
kzykmyzw
0
130
Oracle Base Database Service 技術詳細
oracle4engineer
PRO
15
110k
Data + AI Summit 2026 イベントレポート: 「AIがビジネスで意思決定するデータ基盤」へ
nek0128
0
260
「ちゃんとやっている」は独りよがりだった ― 不安に寄り添うインシデント対応へ / Towards incident response that addresses anxieties
chmikata
1
5.9k
LLM/Agent評価:トップ営業の発言を「正解」にする 〜暗黙的正解による評価を営業資産に変える〜
takkuhiro
1
230
「最後に責任を取るのはチーム」— 人間のPRレビューを最小化してアップデートしたメンタルモデル
jnishime_dresscode
0
880
ソニー銀行におけるビジネスアジリティ向上のためのクラウドシフト戦略
srenext
0
720
End-to-Endで考える信頼性 —LINEアプリにおけるクライアント開発×SRE連携の実践
maruloop
4
4.5k
AI時代の闇と光
tatsuya1970
0
110
ZOZOTOWNの進化と信頼性を両立する負荷試験
zozotech
PRO
2
190
Featured
See All Featured
A brief & incomplete history of UX Design for the World Wide Web: 1989–2019
jct
2
420
Rails Girls Zürich Keynote
gr2m
96
14k
Introduction to Domain-Driven Design and Collaborative software design
baasie
1
900
Gemini Prompt Engineering: Practical Techniques for Tangible AI Outcomes
mfonobong
2
460
Faster Mobile Websites
deanohume
310
32k
Future Trends and Review - Lecture 12 - Web Technologies (1019888BNR)
signer
PRO
0
3.6k
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
11
970
Self-Hosted WebAssembly Runtime for Runtime-Neutral Checkpoint/Restore in Edge–Cloud Continuum
chikuwait
0
650
How People are Using Generative and Agentic AI to Supercharge Their Products, Projects, Services and Value Streams Today
helenjbeal
1
240
Designing for humans not robots
tammielis
254
26k
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
Mobile First: as difficult as doing things right
swwweet
225
10k
Transcript
システム設計とは? 第1回勉強会
そもそもシステムとは何? システム = 受け取ったデータを処理して値を出力する仕組み 例えば、 • 入力値: 購入したい商品のバーコード • 処理:
商品価格の計算 • 出力値: 会計の金額
なぜ設計が必要なの? エクセルで十分じゃない?
なぜシステム設計が必要なの? 要件があるから • 他システムと連携 • データ整合性 • セキュリティ • 数千人規模のユーザーで使いたい
• データ量が膨大だから 要件に合わせるためにシステム設計が必要
システム設計では何を考えるの? ExcelがインストールされたPCで • 在庫管理 • 発注管理 • 人員管理 • etc,,,
上記のことは実現できるがユーザーには不十分 なぜなら要件を満たさないから
システムの概要設計 概要設計のフェーズでは、 • 「何を作るか」を決める • 機能一覧・画面構成・データの流れ • 発注者・PMと合意するための設計 • 例:商品番号が入力されたら価格を取得し、合計金額を計算する
システムの詳細設計 詳細設計のフェーズでは、 • 「どう作るか」を決める • DB定義・API仕様・クラス設計 • エンジニアが実装するための設計 • 例:「入力された商品番号を元に商品マスタテーブルから価格を取得し、レスポンスとし返却する」
システム設計に必要な 4要素 システム設計では単に概要設計の中身を詳細設計に落とし込むだけでは不十分 単にシステムが使えるだけでなく、以下のような場合のことを考えなければならない • システムが稼働するサーバーがダウンしたら? • ユーザー数が増えてサーバーの負荷が増大したら? • データに整合性が保たれるか?失われることはないか?
• パスワードが解読されてしまったら? 上記のようなリスクファクターを洗い出すためにこれから紹介する考え方が必要となる
可用性(Availability) 使用するサービスがダウンした場合、 • 在庫管理システムなら発注できない、在庫数が把握できない • 社内システムなら業務が遂行できない • 銀行のシステムならATMが利用できない、オンラインバンキングが利用できないなどの影響 とりあえず動くシステムとサーバーがダウンしてもバックアップサーバーで稼働するシステムでは、根本の設計か ら異なる
→要件として最初に定める必要がある
可用性(Availability) 可用性には、SLA(Service Level Agreement)という定量的に定められる指標が存在する • SLAの目標値によってシステム設計の内容も変わってくる • 要件側で定める必要がある SLA(%) 年間ダウンタイム
99% 約87時間 99.9% 約8.7時間 99.99% 約52分
スケーラビリティ (Scalability) 例えば以下の場面を想像してみよう • システムを利用するユーザーの数が5倍に増えた • データの量が増えてサーバーのストレージ容量が不足しそう • システムに多くの機能が追加され、サーバーへの負荷が増大した システムは最初の規模のままでは対応できないという問題が発生する
スケーラビリティとは、システムの負荷やデータ量が増えたときに性能を維持しながら拡張できる能力
スケーラビリティ (Scalability) スケーラビリティを実現する方法 • 1台のサーバー強化する(垂直) ⇨簡単だが上限がある、変化する需要には対応しづらい • 複数台のサーバーを用意する(水平) ⇨柔軟に増減できるが、オンプレや自社 DCなど物理設置では上限がある(クラウド向き)
一貫性(Consistency) 例えば以下の場面を想像してみよう • ECサイトで在庫が 1個しかない商品 • 同時に 2人が購入 • 両方の注文が成功してしまった
システム上で在庫が-1個となってしまう システムではデータの矛盾が発生する可能性がある
一貫性(Consistency) 一貫性とは、 • データが常に矛盾のない状態を保つこと 一貫性を実現するには? • トランザクション(DB側で排他制御) • 楽観ロック・悲観ロック •
メッセージキュー(SQSなど)で順番に処理
エクササイズ 1: 人気アイドルのチケット販売 シナリオ: 某人気アイドルのライブチケットが 7/7 20:00より開始 • 過去には通常時の100倍のアクセス数を記録した Question
• サーバーが落ちないようにどう設計する? • アクセスが集中してもパンクしないようにリクエストをどう捌く?
エクササイズ 2: SNSの「いいね」カウンター シナリオ: 某メッシ・某クリロナが SNSに写真を投稿した • 過去の投稿では1時間に100万「いいね」が押された Question •
全てのユーザーに「全く同じ瞬間、全く同じカウント数」を見せる必要がある? • それとも、数秒遅れてもいいから、システムが止まらないことを優先する?