ブログコーナーへようこそ

Service-Oriented Architecture in Cloud
サービス指向アーキテクチャ(SOA)は、複数のサービスエンティティが単一のシステムを通じて通信し、情報を共有できるようにするサービス指向のアプローチです。SOAは「疎結合」と呼ばれる手法を実装することでこれを実現します。 疎結合により、サービスとユーザー間の依存度が低くなります。これにより、サービス機能がどの段階で変更されても、クライアントアプリケーションは中断されることなく動作します。 SOAは複数のサービスの集合体です。アプリケーションは、言語やベンダーに関係なく、さまざまなプラットフォームで利用可能な機能を利用して構築できます。 クラウドにおけるSOAの主な目的は、ユーザーのビジネスと情報技術およびその他のリソースとの連携を強化することです。SOAはビジネスワークフローを改善し、以下のメリットを提供します。 SOAという概念の誕生は、1990年代後半にまで遡ります。サービス指向のインフラストラクチャは、サービスインターフェースを介することで、その都度、綿密な統合作業を行うことなく、ソフトウェア要素の再利用性を確保するための道筋を提示します。 その実装には当初、多大な投資を要するものの、SOAは企業に対してビジネス上の価値をもたらす戦略的目標を提供すると同時に、継続的な進歩を実現します。 サービス指向アーキテクチャの主な利点は何ですか? サービス指向アーキテクチャ(SOA)は、すべてのプロセスが単一のユニットとして稼働する従来のアーキテクチャと比較して、数多くの利点を持っています。SOAの主な利点としては、以下のような点が挙げられます。 市場投入までの期間短縮 開発者は、異なるビジネス領域間でサービスを柔軟に再利用できるため、時間とコストを節約できます。SOAを活用すれば、ゼロから膨大な量のコードを記述するのではなく、既存のサービスを組み合わせてアプリケーションを迅速かつ容易に構築することが可能になります。 効率的な保守 大規模なコードブロックと比較して、小規模なサービスの作成、更新、およびデバッグを行う方が容易です。SOAにおいては、個々のサービスに変更を加えても、ビジネスプロセス全体の機能に悪影響を及ぼすことはありません。 高い適応性 SOAは、先進技術への適応性に優れています。これにより、アプリケーションを効率的かつ費用対効果高く近代化することが可能になります。例えば、医療機関であれば、既存の電子カルテシステムが持つ機能を、最新のクラウドベースシステム上で活用するといったことが実現できます。 クラウドコンピューティングにおけるサービス指向アーキテクチャの重要性 では、SOAはクラウドコンピューティングとどのような関係にあるのでしょうか? クラウドへの移行は、あらゆる企業にとって重要かつ実践的な一歩となります。クラウド環境にSOAを統合することで、企業はパフォーマンスの向上、セキュリティの強化、デプロイの迅速化、監視体制の改善など、多くのメリットを享受することができます。 SOAを採用すれば、クライアント側はサービスの実装に使用されている基盤となるプログラミング言語について、熟知している必要がありません。その特性は、特定の製品、技術、あるいはベンダーに依存しない独立したものです。 SOAとクラウドコンピューティングは、それぞれ独立した技術として並存していますが、これら二つの技術は互いに見事に補完し合う関係にあります。 ビジネスの移行を円滑に進めるためには、まずワークロードにSOAを統合しておくことが有益です。そうすることで、ビジネスモデルへのクラウドコンピューティング統合に伴う複雑さを解消することができます。 サービス指向アーキテクチャ(SOA)は、クラウドプラットフォーム上でのSaaS(Software-as-a-Service)のデプロイを容易にします。一方、クラウド側は、そのプロセスに必要な処理能力やその他のリソースを提供します。 SOAとクラウドを統合することで、組織内の各部門間、さらにはIT部門との連携(コラボレーション)がより円滑になります。 クラウド技術は、そのストレージ機能やその他のプラットフォームサービスを通じて、SOAの基盤となる強固な土台を提供します。 クラウドコンピューティング環境にSOAを導入することで、企業はすでに設計済みのサービスを再利用できるようになります。これにより、コスト効率が向上し、保有するソフトウェア資産の活用度(再利用性)が高まります。 既存のサービスを再利用できるということは、本来であれば必要となる広範かつ詳細なテスト工程を自動的に省略できることを意味します。 SOAを構成する各要素は、比較的自律性の高い独立したユニットとして機能します。そのため、クラウドのリソースを割り当てて拡張を行う際にも、SOAは堅牢なクラウドコンピューティングプラットフォームを構築するための、強力かつ直接的なインターフェースとアーキテクチャを提供します。 開発者は、新しいアプリケーションを構築するために必要なサービスを迅速に見つけ出し、組み合わせることができます。これにより、企業はビジネス環境や技術動向の変化に対して、迅速かつ的確に対応できる能力を獲得します。 SOAのインターフェースは、様々なアプリケーションやサービス活動の間で完璧な連携を図りながら、データや情報の送受信を円滑に処理します。その結果、企業は運用時(ランタイム)における変化への対応力を高めると同時に、システム運用の複雑さやコストを低減させることができます。
Enterprise Resource Planning
企業は常に、コストを削減しつつ、効率と収益を向上させるための新たな手法を模索しています。ERP(企業資源計画)ツールを活用したBPR(ビジネスプロセス・リエンジニアリング)は、こうした課題の解決に寄与する有効な手段ですが、そこには特有の課題も伴います。 企業は、自社の業務運用が導入したERPソリューションのプロセスに確実に適合している状態を確保しなければなりません。 もし両者の間に不整合が生じた場合、組織は当初期待していたようなメリットを享受できなくなってしまいます。最悪の場合、ERPソリューションへの設備投資が徒となり、かえって金銭的な損失を被ることになりかねません。 では、この問題を回避するための解決策とは何でしょうか? それこそが、BPR(ビジネスプロセス・リエンジニアリング)です。本稿では、このBPRの各側面について、これから詳しく解説していきます。 ERPとは何か? ERP(Enterprise Resource Planning:企業資源計画)とは、複数のビジネスプロセスを統合的に管理することです。具体的には、そのツール内に多数のアプリケーションを内包したソフトウェアを指します。 これらのアプリケーションを活用することで、企業内の様々な部門における業務を効率的に遂行することが可能になります。 ERPソリューションは、経営資源や経費、さらにはその他膨大な量のデータを一元的に把握・追跡するのに役立ちます。さらに、組織がそれらの経営資源をいかに有効に活用できたかについて、詳細な分析結果を提供します。 また、どのような成果が達成されたのか、そしてその成果が組織全体の目標や方針の範囲内に収まっているかどうかも可視化します。 BPRとは何か? あらゆる組織は、特定の目標を達成するために、何らかのプロセスに基づいて活動しています。もしこのプロセスに不備があれば、期待される成果を得ることはできません。 さらに、現在運用されているプロセスが、常に100%の効率性を備えているとは限りません。そのため、その効率を向上させるためには、プロセスの再構築(リエンジニアリング)が必要となります。 これが「ビジネスプロセス・リエンジニアリング(BPR)」と呼ばれるものです。これは、利用可能なリソースから最大限の価値を引き出すために、すべての企業が取り組むべき重要な活動です。 BPRとERPはどのような関係にあるのでしょうか? 前述の通り、ERPを導入・運用するには、効果的なビジネスプロセスが不可欠です。もし既存のプロセスが不十分な場合、ERPツールが求める要件に適合させるために、BPR(ビジネスプロセス・リエンジニアリング)が必要となります。したがって、BPRとERPは密接に連携し、両輪となって機能するものと言えます。 ただし、BPRの実施は必須ではありません。組織によっては、ERPを導入する「前」にBPRを実施することを選択する場合もあります。また、ERPパッケージに標準で組み込まれているBPR関連のプロセスやテンプレートを活用することを選ぶ組織もあります。 あるいは、BPRのプロセスを一切行わずに導入を進める組織もあります。しかし、BPRを適切に実施することで、ERP導入によって得られる効果やメリットを、大幅に早期化・最大化することが可能になります。 ERP導入の文脈において、BPRを実施するタイミング(フェーズ)は主に3つに分類されます。具体的には、以下の通りです。 ERP導入前のBPR(ビジネスプロセス・リエンジニアリング) 多くの組織は、このフェーズの実施を選択することを好みます。これにより、現在の業務プロセスやリソース、そしてそれらが実際にどのように機能しているかについて、より明確な全体像を把握できるようになるからです。 こうすることで、組織が直面している課題を洗い出し、その中でも特に優先度を高くして対処すべき課題を特定することが可能になります。 その結果、組織は価値提案の向上や顧客満足度の向上を通じて、自社および顧客双方にとってより大きな利益をもたらすことができるようになります。 また、従業員にとってもこのアプローチは有益です。事前に業務プロセスの変更について周知されているため、十分な準備期間をもって新しいプロセスに適応することができ、日々の業務における混乱や支障を未然に防ぐことが可能となります。 ERP導入におけるBPR(ビジネスプロセス再設計)の推奨 一部の組織は、実績のある既存プロセスから大きく逸脱しないERPソリューションを選択します。そのため、ERP導入におけるBPRは最小限にとどめます。 これにより、導入から適切な価値を引き出し、日常業務に混乱を生じさせないようにしています。 しかし、これには裏があります。適切なERPを選択しないと、逆効果となり、大きな利益ではなく、大きな損失につながる可能性があります。 したがって、重要なのは、組織の標準プロセスに適合する適切なERPパッケージを選択することです。 ERP導入時におけるBPR これは、実行自体は可能であるものの、極めてリスクが高く、現実的とは言えない選択肢です。このアプローチでは、ビジネスプロセスがリアルタイムで変更されていくため、企業の日常業務に甚大な混乱をもたらすことになります。 業務プロセスが変更され、システム導入作業が進行している最中であっても、顧客に対するサービス提供は、平時と同様に滞りなく行われなければなりません。 ここで何らかの業務阻害が生じれば、顧客の不満を招き、組織全体に損害をもたらす結果となりかねません。 結論 ERPにおいて、BPR(ビジネスプロセス・リエンジニアリング)は極めて重要な位置を占めています。そのため、企業がERPの導入を検討する際には、この点に十分留意することが不可欠です。BPRを大掛かりに実施する場合、そのプロセスは少なからず負担の大きいものとなる可能性があります。 こうした煩雑な側面を考慮に入れたとしても、BPRは依然として極めて有益なプロセスであると言えます。なぜなら、そこから得られる価値は、これまでに経験したことのないほど高いものだからです。
Open Source Scrum Tools
プロジェクト管理において、なぜスクラムが重要なのか? スクラムは、ソフトウェア開発の現場において最も重要な手法(メソドロジー)の一つです。なお、スクラムを用いたプロジェクト管理は、アジャイルプロジェクト管理という大きな枠組みの中に位置づけられる点に留意が必要です。 組織にスクラム管理を導入する最大のメリットの一つは、ソフトウェアの頻繁なリリース(公開)が可能になるという点です。 また、スクラムは軽量かつ柔軟なプロセスフレームワークを提供します。このフレームワークは、継続的な改善や漸進的な開発アプローチを歓迎するものであり、プロジェクトの成果物(デリバリー)の提供スピードや品質をさらに向上させる原動力となります。 スクラムはソフトウェア開発コミュニティにおいて広く認知されている概念であり、チームが「ソフトウェアのアジリティ(俊敏性)」を獲得する助けとなります。このアプローチを採用することで、組織は業務の優先順位付けを適切に行うことが可能になります。 スクラムを活用すれば、プロジェクトの実務に携わるメンバーと、その成果物を必要としているステークホルダー(関係者)との間で、円滑な連携や密なコミュニケーションを図ることができます。 このアプローチを取り入れることで、目標を極めて順調なペースで達成することが可能になります。さらに、顧客の要望やニーズに合致した製品を確実に提供できるようになるため、結果としてビジネス価値の向上にもつながります。 そこで、本ブログ記事のこのセクションでは、チームの生産性を高め、かつ目標を期限内に達成する助けとなる、選りすぐりの「オープンソース・スクラム管理ツール」についてご紹介します。これらのオープンソースツールは、自社のニーズに合わせて自由にカスタマイズできるため、比較的容易に導入・適応させることが可能です。 主要なオープンソース・スクラム管理ツール一覧 iceScrum:スクラムツール iceScrumは、2011年に設立されたフランスを拠点とする組織です。このツールは、プロジェクトに対するビジョンを具体化し、実現へと導く手助けをします。 本ツールの主な重要機能は、以下の通りです。 Taiga アジャイル、スクラム、カンバンのメリットをすべて享受できるツールをお探しなら、Taigaは最適な選択肢となるでしょう。 Airbus、Red Hat、HP、Tataなど、数々の有名企業を顧客に持つTaigaは、プロジェクト管理プラットフォームとして高い人気を誇っています。 Taigaの主な機能を見ていきましょう。 ZenTao:スクラムツール ZenTaoは、主にソフトウェア開発(SD)プロジェクトの進捗管理に特化した、業界をリードするオープンソースのプロジェクト管理ツールです。 ZenTaoは、140万人以上のアクティブユーザーを擁する、プロフェッショナルなオープンソース・スクラムツールの代表格の一つとして広く認知されています。 それでは、ZenTaoの主要な機能のいくつかを見ていきましょう。 Tuleap Enaleanは、Tuleapの親組織です。本アプリケーションは、アジャイルやスクラムを用いたソフトウェア開発、プロジェクト設計、Vモデル、ITサービス管理など、多岐にわたる領域の管理に特化しています。 それでは、ZenTaoツールの主要な機能のいくつかを見ていきましょう。 OrangeScrum 近年、OrangeScrumは、プロジェクト管理ツールの中でもトップクラスの評価を得るツールの一つとして注目を集めています。 このツールは、IT、マーケティング、製造、通信という4つの業界に特化した機能を備えています。OrangeScrumは、「戦略」「計画」「実行」「管理」という、プロジェクトにおける4つの基本プロセスに基づいて運用されます。 それでは、この無料かつオープンソースのScrumツールが持つ、主要な機能のいくつかを見ていきましょう。 Bitrix24 Bitrix24は2012年にリリースされました。このツールは、チーム内および顧客との間で円滑なコミュニケーションを実現するための、包括的かつ連携性の高いスイート機能を提供します。 Bitrix24は、今回ご紹介するツールの中で唯一、顧客関係管理(CRM)機能を搭載しているツールです。また、クラウド環境とオンプレミス環境の双方に対応しています。 それでは、このツールの主な特徴を見ていきましょう。
Data Anonymization Tools
データ匿名化ツールとは、保存されたデータと特定の個人との間に結びつきが生じる恐れのある機密情報を、暗号化などの手法を用いて秘匿化する技術のことです。 個人識別情報(PII)を取り扱う組織にとって、データ匿名化は極めて重要な取り組みです。データ匿名化を導入する主たる目的は、データ共有における信頼性と健全性を確保し、向上させることにあります。 自組織のデータ管理において、こうした高度な倫理基準とセキュリティレベルの導入を検討されている場合は、以下に挙げる選択肢をぜひご参照ください。 市場で入手可能な、最適なデータ匿名化ツールは何ですか? ARX ARXのデータ匿名化ツールにおける機能は、以下の4つのセクションに区分されています。構成ビュー、探索ビュー、有用性分析ビュー、およびリスク分析ビューです。 構成ビュー:ここでは、データのインポートや、データに対する特定の変換ルールの作成を行います。同時に、データに対してどのプライバシーモデルや品質モデルを適用するかについても、この段階で決定します。データは多種多様なソースから取り込むことが可能であり、メタデータ、データ型、およびデータ形式を記録・管理する機能も備えています。探索ビュー:入力データに対して適用可能な変換手法の中から、最適な「解の空間(ソリューションスペース)」を設計する場となります。特定のモデルに対して、リスクの許容閾値やデータ品質の要件を満たしているかどうかの確認を行います。有用性分析ビュー:ここでの主要なタスクは、特定のユースケースに対して、ある変換手法がどれほど適切であるかを評価することです。記述統計量や変換後の出力データを用いて、分類モデルを構築することも可能です。リスク分析ビュー:様々な統計モデルを駆使して、プライバシーリスクに関連する各種指標を算出します。さらに、このビューでは、セキュリティ(安全性)を向上させるために優先的に対処すべき属性を特定・検出する機能も提供されています。 入手方法:ARXは「Apache License, Version 2.0」の下で提供されています。これは、自由度の高い(許容的な)フリーソフトウェアライセンスの一種です。 Clover DXのデータ匿名化ツール Clover DXのデータ匿名化ツールは、お客様の重要な本番環境レベルのデータを、匿名化されたデータセットへと変換します。 本ツールの匿名化処理により、本番環境のデータから機密性の高い要素が取り除かれる一方で、データとしての本質的な情報は確実に保持されます。 このデータ匿名化ツールがもたらす主なメリットは以下の通りです。 購入について:Clover DXの全機能を網羅したパッケージを、45日間無料でお試しいただけます。無料期間終了後の正確な料金詳細につきましては、弊社営業チームまでお問い合わせください。 Docbyteのリアルタイム自動匿名化ソリューション Docbyteのリアルタイム自動匿名化ツールは、機密性の高いデータが不当に処理されることを確実に防止します。データプライバシーに関するあらゆる懸念事項に加え、GDPR(EU一般データ保護規則)やその他のデータ関連法規への準拠についても十分に配慮されています。 本ツールの主な特長は以下の通りです。 ご購入について:まずはデモのご依頼からお手続きを開始いただけます。その後、弊社の営業担当チームが、導入に向けた次なるステップについてご案内させていただきます。 Amnesia Amnesiaのデータ匿名化ツールを用いて匿名化されたデータは、元のデータへと逆追跡されることがないよう保証されています。さらに、開発者はReST APIを通じて、このデータ匿名化エンジンを自身の開発プロセスへ容易に組み込むことが可能です。 基本的な仕組みは以下の通りです: 購入・入手について:本ツールはオープンソースとして公開されており、その全コードはGitHubから入手可能です。ご利用にあたっては、システム要件をご確認ください。 BizDataX BizDataXの匿名化ツールは、多種多様なデータタイプの匿名化処理に長けています。 しかし、極めて特殊なシナリオに直面した場合でも、シンプルな拡張機能を利用して独自のロジックを組み込むことが可能です。これは実に画期的な機能と言えるでしょう。 それでは、その主な特長をいくつか簡単にご紹介します。 料金体系:BizDataX匿名化ツールの各種料金モデルについては、以下をご参照ください。各プランの詳細な見積もりにつきましては、同社の営業チームまでお問い合わせください。 g9 Anonymizer g9 Anonymizerは、完全にプログラム可能な匿名化ロジックを搭載したツールです。多種多様なデータベース環境への導入が容易であり、必要に応じて何度でも繰り返し実行することが可能です。 本ツールを使用することで、データベースに対して多岐にわたる処理を実行できます。具体的には、ランダムな値によるデータのマスキング、データレコードの順序入れ替え(シャッフル)、統計的なノイズの付加によるデータのランダム化など、多彩な匿名化処理に対応しています。 g9 Anonymizerの具体的な動作手順: 購入について:本製品の7日間無料トライアル版をご利用いただけます。詳細については、ライセンス利用規約をご確認の上、販売チームまでお問い合わせください。 どのデータ匿名化ツールを選ぶべきか? 正直なところ、私個人の意見によって、皆様のツールに対する判断に先入観を与えてしまうようなことは避けたいと考えています。皆様のビジネスがどのような仕組みで運営されており、具体的にどのようなニーズをお持ちなのかを私が正確に把握しているわけではありませんので、それは不公平なことになってしまうからです。 本稿では、特に人気の高いデータ匿名化ツールのいくつかについて、あくまでも客観的な視点からその実像をお伝えすることに徹しました。したがって、冒頭の問いに対する最適な答えを下せるのは、他ならぬ皆様ご自身であると確信しております。
5 Levels of Virtualization
複数プラットフォームを用いた仮想化の実装レベル コンピューティングの世界において、単一のソフトウェアインスタンスのみを使用するだけでは、もはや十分とは言えません。現在、専門家たちは自身のプログラムやソフトウェアを、複数のプラットフォーム上でテストすることを求めています。 しかし、そうしたテストの実施には、様々な制約が伴い、課題が生じがちです。その解決策となるのが、「仮想化」です。仮想化を活用すれば、ユーザーはオペレーティングシステムやアプリケーションなど、多種多様なプラットフォームのインスタンスを構築することが可能になります。 仮想化の概念は、IBMによって導入された1960年代から存在していました。しかし、クラウドベースのシステムが普及したことにより、期待されていたほどの注目を集めるようになったのは、ごく最近のことです。 仮想化とは、簡潔に説明すると、同一のハードウェア上で複数のコンピュータシステムを同時に稼働させることを可能にする技術です。ハードウェアの具体的な利用方法は、仮想マシンの構成によって異なります。 その最も身近な例として、皆さんがお使いのデスクトップPCやノートPCが挙げられます。普段はWindowsを稼働させているシステムであっても、仮想化技術を用いれば、MacintoshやLinux Ubuntuといった別のOSをその上で実行できるようになります。 さて、仮想化にはいくつかの異なるレベルが存在します。それでは、それらについて詳しく見ていくことにしましょう。 仮想化実装の5つのレベル 仮想化の実装は、決して容易なことではありません。コンピュータは通常、特定のハードウェアに合わせて構成されたOS(オペレーティングシステム)上で動作します。そのため、同一のハードウェア上で別のOSをそのまま動作させることは、現実的には困難です。 この課題を解決するために、「ハイパーバイザー」が存在します。ハイパーバイザーの役割は、仮想OSとハードウェアとの間の「橋渡し役」を担い、仮想環境(インスタンス)が円滑に動作できるようにすることです。 業界で一般的に利用されている仮想化の手法には、主に以下の5つのレベルが存在します。 命令セットアーキテクチャ(ISA)レベル ISAレベルにおける仮想化は、ISAエミュレーションを通じて実現されます。これは、本来とは異なるハードウェア構成向けに記述された、膨大な量のレガシーコードを実行する際に非常に有用です。 こうしたコードは、ISAを介することで仮想マシン上で実行可能となります。 通常であれば実行に追加のレイヤーを必要とするようなバイナリコードも、ISAを利用すればx86マシン上で実行できるほか、多少の調整を加えることでx64マシン上でも動作させることが可能になります。ISAは、このようにしてハードウェアに依存しない(ハードウェア非依存の)仮想マシンを実現する一助となっています。 ただし、基本的なエミュレーションを行うには「インタプリタ」が必要となります。このインタプリタはソースコードを解釈し、ハードウェアが処理可能な形式へと変換する役割を担っています。 ハードウェア抽象化レベル(HAL) その名の通り、このレベルはハードウェアレベルでの仮想化を支援します。動作にはベアハイパーバイザを使用します。 このレベルは仮想マシンの構築を支援し、仮想化を通じてハードウェアを管理します。 I/Oデバイス、プロセッサ、メモリなど、各ハードウェアコンポーネントの仮想化を可能にします。 これにより、複数のユーザーが同じハードウェア上で、多数の仮想化インスタンスを同時に使用できます。 IBMは1960年にIBM VM/370で初めてこの技術を実装しました。クラウドベースのインフラストラクチャに適しています。 したがって、現在Xenハイパーバイザがx86ベースのマシン上でLinuxやその他のOSを実行するためにHALを使用しているのは当然のことと言えるでしょう。 オペレーティングシステム・レベル オペレーティングシステム(OS)レベルにおいて、仮想化モデルはアプリケーションとOSの間に抽象化レイヤーを構築します。 これは、物理サーバーおよびOS上に構築された、ハードウェアとソフトウェアを活用する「隔離されたコンテナ」のようなものです。これらのコンテナはそれぞれ、あたかも独立したサーバーであるかのように機能します。 ユーザー数が多く、かつハードウェアを他者と共有することを望まないような状況において、このレベルの仮想化は極めて有効です。 この方式では、各ユーザーに対して専用の仮想ハードウェアリソースを備えた独自の仮想環境が割り当てられます。これにより、リソースの競合や衝突が生じることなく運用が可能となります。 ライブラリレベル OSのシステムコールは処理が長く、煩雑です。そのため、アプリケーションはユーザーレベルのライブラリが提供するAPIを利用することを選択します。 システムによって提供されるAPIの大部分は、比較的詳細に文書化されています。したがって、こうした状況においては、ライブラリレベルでの仮想化が好まれます。 ライブラリ・インターフェースの仮想化は、APIフックによって実現されます。これらのAPIフックは、システムとアプリケーションとの間の通信経路を制御する役割を担います。 現在利用可能なツールの中には、vCUDAやWINEのように、この技術の実証に成功しているものも存在します。 アプリケーションレベル アプリケーションレベルの仮想化は、特定のアプリケーションのみを仮想化したい場合に有用です。これは、プラットフォームや環境全体を仮想化するものではありません。 オペレーティングシステム上において、アプリケーションは単一のプロセスとして動作します。そのため、この方式は「プロセスレベル仮想化」とも呼ばれています。 一般的に、高水準言語を用いて仮想マシン上でプログラムを実行する際に有効です。この構成では、アプリケーションは仮想化レイヤーの上に位置し、その仮想化レイヤーがさらにアプリケーションプログラムの上に配置される形となります。 そして、そのアプリケーションプログラム自体は、オペレーティングシステム上に存在しています。 高水準言語で記述され、アプリケーションレベル仮想マシン向けにコンパイルされたプログラムであれば、この環境下で円滑に実行することが可能です。 結論 仮想化には5つのレベルが存在しますが、すべての企業がそれらすべてを利用する必要はありません。どのレベルの仮想化を選択すべきかは、各企業がどのような業務に取り組んでいるかによって異なります。 企業は一般的に、クロスプラットフォーム・アプリケーションの開発やテストを行う際に、仮想マシンを活用する傾向にあります。クラウドベースのアプリケーションが普及の一途をたどる中、仮想化は今や世界中の企業にとって不可欠な要素となっています。
PaaS vs. SaaS
多くの企業が、自社のサービスの大部分をクラウドプラットフォームへと移行させています。この傾向は、世界的な新型コロナウイルスのパンデミックを機に、さらに加速する動きを見せています。多くの企業(およびその従業員)がリモートワーク体制へと移行したことに伴い、各社はクラウド導入ソリューションの採用を進めています。現在、市場には多種多様なクラウドコンピューティングモデルが存在します。どのクラウドモデルが最適であるかは、個々のニーズによって異なります。本ブログでは、そうしたモデルの中から、「Platform as a Service(PaaS)」と「Software as a Service(SaaS)」という2つのモデルについて解説します。 PaaS vs. SaaS:主な相違点 PaaS vs. SaaS:より人気があるのはどちらか? 上記のグラフから、Google検索トレンドに基づくと、これら2つのツールの中ではSaaSの方がより広く普及していることが分かります。 しかしその一方で、PaaSへの関心が一時的に急上昇し、検索クエリ数においてSaaSを上回る時期も見受けられます。全体として、過去5年間の推移を見ると、SaaSの方がより高い人気を博しているという結果になりました。 PaaS 対 SaaS:導入形態 PaaS(Platform-as-a-Service)として一般に知られるサービスは、企業に対し、アプリケーション開発に必要なフレームワークを提供するクラウドコンピューティングプラットフォームです。 端的に言えば、開発者がツールに関する煩わしさを一切気にすることなく、自身のスキルを磨く作業に専念できる環境を提供するプラットフォームと言えます。 一方、SaaS(Software-as-a-Service)として一般に知られるサービスは、チーム向けのソフトウェアをユーザーに提供するクラウドコンピューティングプラットフォームです。通常、これはクラウドプラットフォーム上でホストされるサブスクリプション(定額利用)モデルを採用しており、一定期間、ソフトウェアを借り受けて利用することができます。 PaaS 対 SaaS:アプリケーション PaaSは、多数のメンバーが同一のプロジェクトに取り組むような状況において、特にその有用性を発揮します。とりわけ、自社利用やクライアント向けに独自のカスタムアプリケーションを開発する必要がある場合に、最も適した選択肢となります。 PaaSを利用すれば、既存のアプリケーションに変更や修正を加えたり、あるいは独自のアプリケーションを新規に開発したりする上で、極めて高い柔軟性を確保することができます。 一方、SaaSの場合は、サードパーティが提供するソフトウェアを利用する形態であるため、独自のカスタムアプリケーションを開発することはできません。SaaSは、主にOPEX(運用費用)のカテゴリーに分類されるプラットフォームです。 したがって、独自のアプリケーションを開発するためのリソースが十分に確保できない状況であれば、SaaSはまさに理想的なソリューションとなります。また、スタートアップ企業などで、多額の設備投資(CAPEX)を要するリソースへの投資を避けたいと考えている場合にも、SaaSがその課題に対する有効な解決策となるでしょう。 PaaS 対 SaaS:事例 PaaSの主な事例としては、Google App Engine、Apache Stratos、OpenShift、Windows Azure、AWS Elastic Beanstalk、Herokuなどが挙げられます。 SaaSの主な事例としては、Google Apps、CADソフトウェア、Cisco WebEx、GoToMeeting、HubSpot、Zendesk、Office 365、Adobe Creative Cloudなどが挙げられます。 PaaS 対 SaaS:スケーラビリティと可用性 PaaSはスケーラビリティを備えていますが、その拡張には一定の制限があります。また、PaaSは通常、極めて高い可用性を維持しています。その可用性が損なわれるのは、データ障害が発生した場合や、サービスプロバイダー側​​のシステムに問題が生じた場合に限られます。 一方、SaaSは、サービスプロバイダーがソフトウェア全体を提供しているため、必要に応じてリソースを拡張(スケールアップ)したり縮小(スケールダウン)したりすることが、PaaSよりもはるかに容易です。SaaSもまた高い可用性を誇りますが、サービスプロバイダーが複数のデータセンターを用いたバックアップ体制を構築していない場合に限り、サービスが利用不能となる可能性があります。 PaaS 対 SaaS:適性 PaaSは、インフラストラクチャ全体がすでに整備されている既存の組織により適しています。また、独自の要件(カスタマイズニーズ)を抱えており、その実現を自社のITチームに委ねているような組織にも適しています。 一方、SaaSは拡張性および可用性が非常に高いため、組織の規模を問わずあらゆる組織に適しています。 さらに、SaaSにかかるコストはPaaSに比べて大幅に低く抑えられるため、企業はカスタマイズが不要な領域においては、SaaSソリューションを選択する傾向にあります。 […]