![](/_next/image?url=https%3A%2F%2Fstorage.googleapis.com%2Fenvader-article-images%2Farticle-image-3_2.jpg&w=3840&q=75)
こちらの記事では、性能のためのスケーリングについて解説します。
スケーリングとは
単にスケーリング(Scaling)と言った場合、それは拡大縮小のことです。
ITシステム開発におけるスケーリングは、画像・映像のスケーリングと性能管理手法としてのスケーリングという意味があります。この記事では後者を扱い、以降、単に「スケーリング」と記述した場合はこれのことを指します。
性能管理手法としてのスケーリングとは
性能管理の文脈で言うスケーリングとは、処理量に見合った性能をリソースの減増によって実現することです。
性能とは、サービス提供におけるリソース利用の効率性です。簡単に言えば、ITシステムのスピードです。性能の詳細については以下の記事をご参照ください。 https://envader.plus/article/17
スケーリングには、垂直スケーリングと水平スケーリングの2種類があります。
- 垂直スケーリング
処理を担う各コンポーネントの性能を増減させることです。例えばサーバを対象にするのであれば、ハードウェアをより良いものに交換したり、逆に必要ないのでより性能の低いものに変えたりすることです。性能を上げる場合はスケールアップ、下げる場合はスケールダウンと呼びます。
- 水平スケーリング
分散処理を担うコンポーネントの数を増減させることです。例えばサーバを対象するのであれば、サーバを複数用意してそれらで分散処理したり、必要なければサーバ数を減らしたりすることです。増やす場合はスケールアウト、減らす場合はスケールインと呼びます。
垂直スケーリングと水平スケーリングの使い分け
垂直スケーリングと水平スケーリングはそれぞれメリット・デメリットが異なり、絶対的な優劣をつけられるものではありません。目的に応じて適切に使い分ける必要があります。
垂直スケーリング・水平スケーリングの長短
垂直スケーリングと水平スケーリングのメリット・デメリットが問題となる主要な側面は、メンテナンス量・実装難易度・ダウンタイム・性能限界の4つです。
- メンテナンス量
メンテナンス量はオンプレミスの時に問題となります。
この点ではスケールアップが優れています。スケールアウトがコンポーネントを増やすためにメンテナンス対象も増えるのに対し、スケールアップは既存コンポーネントをより高性能なものに置きかえるだけのためメンテナンス対象は増えません。
- 実装難易度
実装難易度についてはスケールアップの方が簡単です。ハードウェアを交換するだけのため、実装への影響は少ないからです。「少ない」であって「無い」と言い切れないのは、チューニング等パフォーマンスを考慮した実装が必要になったり不要になったりする可能性がゼロとは言い切れないためです。
スケールアウトする場合、複数コンポーネントで分散処理を行っているために、「どう分散するか」「コンポーネント間でデータ整合性をどう保つか」という問題が発生し、これに対応する必要があり難易度が高くなります(この件は後ほど詳述します)。
- ダウンタイム
ダウンタイムについてはスケールアウトに分があります。ダウンタイムとは、サービスの停止時間のことです。スケールアップはハードウェア自体の交換を行うためダウンタイムは避けられません。しかしスケールアウトは分散処理対象を増やすだけのため、トラブルがなければダウンタイムは必要ありません。
- 性能限界
性能限界についてはスケールアウトであればありません。一方でスケールアップはハードウェアの問題ゆえに物理的な制約が存在し、これによって向上できる性能には限界があります。
どう使い分けるか?
どうスケーリングさせるのが良いかは、どのようなサービスかによります。
例えば比較的小規模なサービスであるがゆえにダウンタイムも性能限界も許容できるのであればスケールアップを利用するかもしれません。逆に大規模で、かつある程度データの一貫性を犠牲にしても良いのであれば、スケールアウトを利用することになるでしょう。
全てを満たすのは難しい・コストがかかる事が多く現実的ではない場合、何は必須なのか・何は許容できるのか・許容不能な部分があるとすれば何をすれば許容範囲にまで制御できるのかを自身のサービスに合わせて検討しましょう。
水平スケーリングの難しさ
先述のように、水平スケーリングには垂直スケーリングにはない難しさがあります。「どう分散するか」「コンポーネント間でデータ整合性をどう保つか」です。
どう分散するか――負荷分散の問題
スケールアウトにより複数のコンポーネントが並列稼動している場合、個々のアクセスをどのコンポーネントに繋げるか=負荷分散の設計が問題になります。どのように分散するかは要件により、適切な方式を選択する必要があります。
データ整合性をどう保つか――データ整合性の問題
スケールアウト対象のコンポーネントがデータを持つ場合、データが分かれる以上、データ間の整合性の保持が問題になります。整合性保持の設計が必要になります。
この点で最も大きな問題を抱えるのはRDBです。一般的にRDBのスケールアウトは難しいとされます。基本的にRDBは一貫性を求められるデータを扱いますが、この特性のデータはスケールアウトと相性が良くありません。問題となるのは更新処理です。
まず、複数RDBそれぞれにまったく同じデータを保持するケースを考えましょう。この場合、全てのRDBが同値になるように処理せねばならず、余分な同期処理の分、RDBが1つしかない時よりも遅くなり得ます。性能向上になりません。これを回避するために複数RDBがそれぞれ異なるデータを保持するようにしたら、複数RDB間で一貫性を求められるデータ処理(例えばRDB1とRDB2があったとして、RDB1のデータから数値を引いてその分をRDB2に足すような処理)をした時にトラブルが起きて処理が中断してしまった場合に備える複雑な仕組みが必要となります。
DBサーバ以外のサーバは基本的にデータを保持しないため、このような問題は生じません。セッションを保持する可能性がありますが、この場合はRDBほどではありませんがRDBと類似の問題が生じます。DBでも、NoSQLで扱われるのは一貫性を求めないデータであることが基本のため、こちらでもRDBのような問題は生じにくいです。
オンプレミス・クラウドのスケーリング
スケーリングの「容易性」「費用」は、オンプレミスかクラウドかで変わります。
スケーリングの容易性
スケーリングの容易性では、クラウドに圧倒的な分があります。
オンプレミスではスケーリングのためにはそれなりの準備と日数を必要とします。まず必要なリソースの見積もり=サイジングが必要です。いざスケーリングするとなると、ハードウェアの調達作業が必要ですし、調達できたらハードウェアの各種設定作業=キッティングも必要になります。
しかしクラウドであれば設定さえすればスケーリングが完了します。
スケーリングの費用
費用面に関しては、オンプレミスとクラウドのいずれが安いかはケースバイケースです。
スケーリング自体に必要な費用、スケーリング後の維持費用(オンプレミスであれば電気代等もかかります)、ノウハウを持つ人材の確保コスト等、様々な費用があり得ます。多角的な観点から費用を計算するべきでしょう。
【番外編】USBも知らなかった私が独学でプログラミングを勉強してGAFAに入社するまでの話
![IT未経験者必見 USBも知らなかった私が独学でプログラミングを勉強してGAFAに入社するまでの話](/_next/image?url=%2Fcommons%2Fbanners%2Fbanner-note01.jpg&w=3840&q=75)
プログラミング塾に半年通えば、一人前になれると思っているあなた。それ、勘違いですよ。「なぜ間違いなの?」「正しい勉強法とは何なの?」ITを学び始める全ての人に知って欲しい。そう思って書きました。是非読んでみてください。
「フリーランスエンジニア」
近年やっと世間に浸透した言葉だ。ひと昔まえ、終身雇用は当たり前で、大企業に就職することは一種のステータスだった。しかし、そんな時代も終わり「優秀な人材は転職する」ことが当たり前の時代となる。フリーランスエンジニアに高価値が付く現在、ネットを見ると「未経験でも年収400万以上」などと書いてある。これに釣られて、多くの人がフリーランスになろうとITの世界に入ってきている。私もその中の1人だ。数年前、USBも知らない状態からITの世界に没入し、そこから約2年間、毎日勉学を行なった。他人の何十倍も努力した。そして、企業研修やIT塾で数多くの受講生の指導経験も得た。そこで私は、伸びるエンジニアとそうでないエンジニアをたくさん見てきた。そして、稼げるエンジニア、稼げないエンジニアを見てきた。
「成功する人とそうでない人の違いは何か?」
私が出した答えは、「量産型エンジニアか否か」である。今のエンジニア市場には、量産型エンジニアが溢れている!!ここでの量産型エンジニアの定義は以下の通りである。
比較的簡単に学習可能なWebフレームワーク(WordPress, Rails)やPython等の知識はあるが、ITの基本概念を理解していないため、単調な作業しかこなすことができないエンジニアのこと。
多くの人がフリーランスエンジニアを目指す時代に中途半端な知識や技術力でこの世界に飛び込むと返って過酷な労働条件で働くことになる。そこで、エンジニアを目指すあなたがどう学習していくべきかを私の経験を交えて書こうと思った。続きはこちらから、、、、
エンベーダー編集部
エンベーダーは、ITスクールRareTECHのインフラ学習教材として誕生しました。 「遊びながらインフラエンジニアへ」をコンセプトに、インフラへの学習ハードルを下げるツールとして運営されています。
![RareTECH 無料体験授業開催中! オンラインにて実施中! Top10%のエンジニアになる秘訣を伝授します! RareTECH講師への質疑応答可](/_next/image?url=%2Fcommons%2Fbanners%2Fbanner-raretech-trial-lesson01.jpg&w=3840&q=75)
関連記事
![](/_next/image?url=%2Fcommons%2Fimages%2Fthumbnail-note.jpg&w=3840&q=75)
2020.02.25
完全未経験からエンジニアを目指す爆速勉強法
USBも知らなかった私が独学でプログラミングを勉強してGAFAに入社するまでの話
- キャリア・学習法
- エンジニア
![](/_next/image?url=https%3A%2F%2Fstorage.googleapis.com%2Fenvader-article-images%2Fiac%2FIaC-1.png&w=3840&q=75)
2023.04.16
IaCとは?IaCのメリットやデメリット、Terraformなどの構成管理ツールの特徴を紹介
IaC(Infrastructure as Code)とは、サーバーやネットワーク、ストレージなどをはじめとしたインフラの構成をコード化し、その構成や管理を自動化する手法のことです。
- プログラミング
- インフラエンジニア
![](/_next/image?url=https%3A%2F%2Fstorage.googleapis.com%2Fenvader-article-images%2Flinuc%2F001.jpg&w=3840&q=75)
2024.05.02
Linux認定試験「LinuC」でクラウド時代の即戦力インフラエンジニアに
LinuCは、クラウド技術を含めた幅広いLinux技術を網羅した新しいLinux技術者認定試験です。2018年にスタートし、2020年には仮想化・コンテナ技術などを追加する改訂が行われ、2023年には最上位資格としてLinuCシステムアーキテクトが追加されました。LinuCを取得することで、自身のLinux技術を証明し、就職や転職、キャリアアップに繋げることができます。
- インフラエンジニア
- Linux
![](/_next/image?url=https%3A%2F%2Fstorage.googleapis.com%2Fenvader-article-images%2Fbind-chroot-first-half%2Fchroot_handson_02.png&w=3840&q=75)
2023.10.01
【BIND高度実践】chroot環境を構築してみよう【前編】
こちらの記事では、BINDを利用したDNSサーバーにchroot環境を構築する手順をハンズオン形式でご紹介します。
- インフラエンジニア