コンピュータ運用方式の変化について(2016/01時点)


製造技術の向上・オフショア等利用によるコンピュータ等の価格低下と仮想化技術の向上・浸透により、 ITの軸足がクラウドサービスへと変化しつつありますので、 そちらについて、過去の経緯を含めつつ、現状をまとめてみました。

作成日:2016/03/21、2016/04/13:タイトルの「IT」を「コンピュータ運用方式」に変更

コンピュータ運用方式の変化

処理集中型・分散型とその他関連技術

コンピュータ使用用途等

コンピュータ運用方式の変化
時期 分類1 分類2 定着した新技術等 特徴等
1960年~ 処理集中 メインフレームCOBOL 当初は、個人毎にコンピュータを使用するのではなく、高性能なメインフレーム等1台で、単純に、集中的に処理する運用が多かった。
1970年~ 処理分散 C/S UnixPCサーバCObjective-CC++VisualBasic その後、個人毎でのコンピュータの利用、又、高価なメインフレーム等から、安価な複数のPCサーバに ダウンサイジングする事で、 運用費用を抑えようとするトレンドが生まれた結果、処理負荷分散を目的としたC/S型が採用される事が多くなった。
C/S型では、クライアントで処理する為に必要な機能・データ等をクライアント上に配置する事等で、 サーバに頼らなくても、クライアントで分散的に処理する事が可能となった。
その結果、安価に高速な分散システムを構築する事が可能となったが、同時に、管理するコンピュータが増加した為、運用管理が難しくなる問題が発生した。
1990年~ 処理集中型 Web型 HTMLWebブラウザJavaPHPLinuxホスティングサービス その後、インターネットが普及する事により、不特定多数ユーザは、各組織の様々なサービスを利用する事が可能となったが、 不特定多数ユーザに、様々なサービスを使用する為の専用アプリケーション(以後、アプリと記載)を、サービス単位で、導入してもらう事が難しかった為、今度は、Webブラウザ上で、 入力した命令をサーバで集中的に処理するWeb版処理集中型に戻った。
又、この時期より、不特定多数のユーザへWeb向けサーバを貸し出すホスティングサービスの利用が浸透してきた。
2000年~ 処理分散型 リッチクライアント AjaxFlash.net 基本的に、Web型は、Webブラウザの命令を元に、サーバ側で画面を作成し、返却する単純な仕組みの為、一旦サーバに処理を戻さない事には、 Webブラウザだけでは、ほとんどの処理ができないので、入力しながら、サーバ内データを検索する等のC/S型のリッチな画面等を 使用していたユーザより、処理効率面での不満が出る事となった。
その課題を克服する為に、今度は、WebブラウザをC/S型のクライアントとして、処理を実行するリッチクライアントという運用方式が考案された。
リッチクライアントは、Web版C/Sなので、C/S型に一部戻る事になった。
併用型 Web型、C/S型 AndroidiOS リッチクライアントを採用したとしても、処理が低速で入力が非効率なWebブラウザに依存している事に変わりがない為、 過去にC/Sで実現可能であった、OSの機能を活かしたリッチな画面入力等を再現する事は難しい。 本問題を解消する為、リッチクライアント型とは別に、使用頻度の高いサービスについては、専用アプリをパソコンに導入して頂き、 それ以外については、Webブラウザを使用する併用型の運用も多くなっている(スマフォアプリも同範疇)。 ただし、本運用では、開発対象が増加する問題がある。
2010年~ 処理集中型 クラウド型 仮想化、VMwareVPSAWSGoogle App Engine クラウドサービスは、サーバ・ソフトウェア・アプリを時間単位等で、インターネット経由で借り受けるサービスで、主に下記の3種類に分類される。
IaaS(Infrastructure as a Serviceの略)
PaaS(Platform as a Serviceの略)
SaaS(Software as a Serviceの略)

IaaSでは、サービス提供元の大規模サーバの資源を借りる事により、 小~中規模程度のアプリでも、大規模サーバのスケールメリットを享受する事で、安価に、サービスを運用できるメリットがある。 本メリットは、ホスティングサービスと同様であるが、クラウドサービスでは、 仮想化技術の発展により、 1サーバ全てを借りなくても、1サーバの中に、ユーザ毎に別々の論理的サーバを立てる事が可能となった為、 全権限(root権限)を それぞれのユーザで保持できる。その結果、アプリ等を自由に導入できるようになる等、運用自由度が高くなった。 デメリットとしては、ホスティングサービスと同様に、大規模アプリで使用する際は、費用が高くなる事があげられる。

PaaSでは、IaaSと同様のサービスとなるが、プラットフォームとなるアプリを組み合わせて、使用する等、サービスの粒度が大きい為、運用がしやすい特徴がある。 又、アプリのスケーラビリティ・性能を一時的に高める事ができる等、柔軟性の高い運用が可能となっている。

SaaSでは、常にパッケージソフトウェアの最新版を使用できる、又、ソフトウェアの使用時間が短い場合に費用が低くなるメリットがあるが、 使用時間が長くなると全体的な費用は高くなるデメリットがある。

▲最上部に戻る

処理集中型・分散型とその他関連技術
分類 関係する技術 特徴等
処理集中型 メインフレーム等 1台の高速なコンピュータで、集中的に処理を実行する事で、管理しやすい。
処理分散型 サーバ並列マルチスレッドプログラミング 処理集中型とは異なり、複数のコンピュータを並列で処理させる事により、安価なコンピュータでも、高速な処理を実現可能。
※複数のコンピュータを並列で使用する事により、仮に1台コンピュータが故障しても、処理継続が可能
最近のCPUは、マルチコアとなっている為、この状態は、並列処理と同様な状態と考える事もできるが、 CPUマルチコアは、マルチスレッドプログラミングを考慮したアプリでなければ、その恩恵を受ける事ができない。
処理集中型 サーバ仮想化 Windows、Linux等コンピュータは、複数機能を1つのサーバで、並行運用可能だが、 複数機能を1つのサーバに導入すると別機能の影響を受ける可能性が高くなるリスクがある。
その問題を解消する為に、1つの物理的サーバから、複数の論理サーバを作成するサーバ仮想化技術が発展してきた。
本技術を使用する事により、1つの物理的サーバで、全権限(root権限)を保持した複数の論理サーバを運用できる為、 他機能からの影響を受けづらくする事が可能となった。
その他 LXC(Linux Containersの略) アプリを構成する要素には、Webサーバ、APサーバ、DBサーバ等が存在するが、 それぞれ、各環境への導入条件等が異なる為、例えば、Windows等で構築した環境をそのまま、Linuxに移動し、実行する事はできない。
この問題を解消する為に、環境構築時に、Webサーバ、APサーバ、DBサーバ等をコンテナ上に構築する Docker等LXCが発展してきている。
こちらの技術を使用する事により、Windowsで構築した環境をそのまま、Linuxに移動する事が可能となる。
※Javaで作成したアプリが、WindowsやLinux等のどの環境でも動作する概念と同様

▲最上部に戻る

コンピュータ使用用途等
主な使用用途 コンピュータ種類等 基本的なUI ライセンス提供有無 主要開発言語 備考
クライアントから受信した命令を集中処理し、結果をクライアントへ返却 メインフレーム CUI 無(メーカ独自) アセンブラ、COBOL ミッションクリティカル等、信頼性を求められるシステムで、現在も使用される。
Unix 有(プログラムソース提供有で、更にライセンス販売している為、様々な組織に普及した為、現在は様々なバージョンが存在) C
Linux 有(オープンソース(以後、OSSと記載)) C、C++ サーバ使用でのデファクトスタンダードになりつつある。一部クライアント用途での使用も有。
Windows Server GUI、一部CUI 有(クローズドソース) WindowsのGUIをサーバでも、使用したいユーザが利用。
自機能の使用、又、ネットワーク・インターネット経由でのサーバ等使用 Mac(PowerPC) 無(メーカ独自) 現在は、Mac(Intelベース)に移行済。
Windows 有(クローズドソース) 様々なコンピュータ会社へライセンスを販売する事により、大成功を収めた、デスクトップ使用でのデファクトスタンダード。
Mac(Intelベース) 無(メーカ独自) C、Objective-C、C++、Swift Apple向けアプリを開発する為には、Apple社のコンピュータが必要。
Windows、Linux等でも使用しているIntelCPUを採用した事により、Windows、Linux等の併用可能(Apple社以外のPCでのApple社OS等の使用はライセンス上、不可)。
iOS Objective-C、Swift スマフォ・タブレット分野で、世界ではAndroidよりもシェアが低いが、日本ではシェア1位。
Android 有(OSS) Java、C++ スマフォ・タブレット分野で、世界シェア1位となる等、デスクトップのWindowsとほぼ同様の立ち位置を獲得。

▲最上部に戻る