Wiki: /* 概要 */

2024-11-12T18:18:32Z

概要

@@ 2行目: / 2行目: @@
 スケーリングとは、システムの処理能力を必要に応じて拡張または縮小することである。<br>
 <br>
-主に、以下に示すような2種類がある。<br>
+クラウドスケーリングの本質は、システムのリソースを需要に応じて柔軟に調整できる能力にある。<br>
 * 垂直スケーリング (スケールアップ / スケールダウン)
 * 水平スケーリング (スケールアウト / スケールイン)
 <br>
 特に、IoTシステムを使用する場合では、以下に示すような場面でスケーリング機能が重要となる。<br>
@@ 22行目: / 45行目: @@
 ** 新機能の追加
 <br>
-スケーリングを適切に行うことにより、システムの安定性を保ちながら、コストを最適化することが可能となる。<br>
+クラウドのスケーリングは、技術的な側面だけでなく、運用面やビジネス面も考慮した総合的なアプローチが必要となる。<br>
 <br><br>

Wiki: ページの作成:「== 概要 == スケーリングとは、システムの処理能力を必要に応じて拡張または縮小することである。

主に、以下に示すような2種類がある。
* 垂直スケーリング (スケールアップ / スケールダウン) * 水平スケーリング (スケールアウト / スケールイン)
特に、IoTシステムを使用する場合では、以下に示すような場面でスケーリング機能が重…」

2024-11-12T18:11:03Z

ページの作成:「== 概要 == スケーリングとは、システムの処理能力を必要に応じて拡張または縮小することである。 主に、以下に示すような2種類がある。 * 垂直スケーリング (スケールアップ / スケールダウン) * 水平スケーリング (スケールアウト / スケールイン) 特に、IoTシステムを使用する場合では、以下に示すような場面でスケーリング機能が重…」

新規ページ

== 概要 ==
スケーリングとは、システムの処理能力を必要に応じて拡張または縮小することである。 
 
主に、以下に示すような2種類がある。 
* 垂直スケーリング (スケールアップ / スケールダウン)
* 水平スケーリング (スケールアウト / スケールイン)
 
特に、IoTシステムを使用する場合では、以下に示すような場面でスケーリング機能が重要となる。 
* デバイス数の増加した場合
** 新しいセンサの追加する。
** 新しい設備の導入する。
** 新拠点の追加する。
*: 
* データ量が変動する場合
** 収集頻度の変更
** センサの種類追加
** 詳細なデータ収集の開始
*: 
* 処理要件の変化する場合
** リアルタイム分析の追加
** データ保存期間の延長
** 新機能の追加
 
スケーリングを適切に行うことにより、システムの安定性を保ちながら、コストを最適化することが可能となる。 
 

== 垂直スケーリング (スケールアップ / スケールダウン) ==
==== 垂直スケーリングとは ====
垂直スケーリングとは、単一のサーバのスペックを上げ下げすることである。 
 
==== 具体例 ====
# スケールアップする場合

【初期状態】
CPU: 2コア
メモリ: 4[GB]
ストレージ: 100[GB]

【増強後】
CPU: 4コア
メモリ: 8[GB]
ストレージ: 200[GB]
 

== 水平スケーリング (スケールアウト / スケールイン) ==
水平スケーリングとは、サーバの数を増減させることである。 
 
==== 具体例 ====
# スケールアウトする場合

【初期状態】
Webサーバー × 2台
毎秒1000リクエストを処理

【増強後】
Webサーバー × 4台
毎秒2000リクエストを処理
 

== 具体的なスケーリングの例 (IoTシステムの場合) ==
==== 小規模な工場での利用例 ====
# 工場が増設された場合

【初期状態】
センサ数 : 100個
データ収集間隔 : 1分毎
1日のデータ量 : 約144,000レコード

(100センサ × 60分 × 24時間)

サーバ構成
MQTTブローカー : 1台
データベース : 1台

【拡大後】
センサ数 : 1000個 (10倍)
データ収集間隔 : 1分毎 (変更なし)
1日のデータ量 : 約1,440,000レコード (10倍)

サーバ構成
MQTTブローカー : 3台 (負荷分散)
データベース : 2台 (マスター / スレーブ)
ロードバランサー : 1台 (追加)
 
==== 自動スケーリングの動作例 ====
【平常時】
アクティブなサーバ : 2台
CPU使用率 : 30%
メモリ使用率 : 40%

【急激なアクセス増加時】
条件 : CPU使用率が80%を超える
動作 : 新しいサーバを自動追加

【アクセス減少時】
条件 : CPU使用率が20%未満が30分継続
動作 : 余分なサーバを自動削除
 

== スケーリングが重要となる具体的なケース ==
==== 時間帯による負荷変動 ====
【朝9時の工場稼働時】
デバイス接続数 : 1000
データ転送量 : 100MB/分
サーバ4台で対応

【夜間の低稼働時】
デバイス接続数 : 100 (1/10になる場合)
データ転送量 : 10MB/分 (1/10になる場合)

これにより、サーバ1台に自動縮小する。
 
==== イベント時の急激な負荷増加 ====
【通常時】
センサからのデータ受信 : 1000件/分
サーバ数 : 2台

【設備点検時 (全センサの一斉データ送信)】
センサからのデータ受信 : 10000件/分
サーバ数を自動で8台に増加させる
 

== クラウドサービスでのスケーリングのメリット ==
==== コスト最適化 ====
【従来の固定インフラ】
ピーク時に合わせて常時10台のサーバを用意
月間コスト : $1000

【クラウドの自動スケーリング】
平常時：2台（$200/月）
ピーク時のみ10台 (一時的なコスト増)
月間平均コスト : $400
 
==== 可用性の向上 ====
【障害発生時】
# 異常を検知 (サーバA停止)
# 自動で新しいサーバBを起動
# ロードバランサが自動で振り分け先を変更

これにより、サービスの停止を回避する。
 

{{#seo:
|title={{PAGENAME}} : Exploring Electronics and SUSE Linux | MochiuWiki
|keywords=MochiuWiki,Mochiu,Wiki,Mochiu Wiki,Electric Circuit,Electric,pcb,Mathematics,AVR,TI,STMicro,AVR,ATmega,MSP430,STM,Arduino,Xilinx,FPGA,Verilog,HDL,PinePhone,Pine Phone,Raspberry,Raspberry Pi,C,C++,C#,Qt,Qml,MFC,Shell,Bash,Zsh,Fish,SUSE,SLE,Suse Enterprise,Suse Linux,openSUSE,open SUSE,Leap,Linux,uCLnux,Podman,電気回路,電子回路,基板,プリント基板
|description={{PAGENAME}} - 電子回路とSUSE Linuxに関する情報 | This page is {{PAGENAME}} in our wiki about electronic circuits and SUSE Linux
|image=/resources/assets/MochiuLogo_Single_Blue.png
}}

__FORCETOC__
[[カテゴリ:Web]]

クラウド - スケーリング - 版の履歴

Wiki: /* 概要 */