タグ別アーカイブ: PaaS

Red HatがEnterprise LinuxとPaaSプラットホームOpenShiftでDockerをサポートへ | TechCrunch Japan

Dockerの最初のリリースは約1年前だったが、またたくまに人気が拡大し、従来の仮想化技術に代わってソフトウェアコンテナを使いたいと願うデベロッパたちのツールとして広まった。商用レベルでDockerプロジェクトの面倒をみている組織が、Docker.io だ。

Red Hat Enterprise Linux 7は現在ベータで、コンテナとしてはDockerをメインにサポートしている。Dockerの側では、企業がRed Hat Enterprise LinuxとOpenShiftをベースとしてパイロット事業を作っていくためのサービス、JumpStartを発表した。このサービスは企業にDockerに関する教育訓練と、Docker Registryのインストール、そしてDockerの商用サポートを提供する。

Red HatのCTO Brian Stevensは今日の発表声明の中で次のようにのべている: “Red HatにはLinux Containersをはじめ、革新的な技術の開発と投資と育成に貢献してきた伝統があり、またオープンソースの世界に対しても長年、数多くの寄与貢献を果たしてきた。Dockerの技術は、企業のコンテナ採用を阻んでいたバリヤを取り除くものであり、その使いやすさと、アプリケーションのパッケージングとインフラストラクチャの統合ぶりは、われわれにとってきわめてエキサイティングである”。

引用元: Red HatがEnterprise LinuxとPaaSプラットホームOpenShiftでDockerをサポートへ | TechCrunch Japan.

Snapchatを支える技術:768台のRedisをGoogleクラウドで構築 #gcpja – Qiita

Snapchatの成功のカギがGCPのPaaSであるApp Engineであったことは、じつは昨今のImmutable InfraやDockerのムーブメントに通じるところがある。それは、

App EngineではアプリケーションをDisposableかつStatelessでShared Nothingに設計しなくてはならない

アプリケーションをVMではなく超軽量なコンテナで運用し大規模にスケールアウトさせる

構成管理とデプロイをRepeatableにしてバージョンアップやフェイルオーバーに手間をかけない

といった点だ(ただしApp EngineにはDockerほどのプラットフォーム透過性はない)。例えばApp EngineにGoのアプリケーションをデプロイすると、およそ50ms(!)ほどでコンテナが起動し、トラフィックのスパイクがあるとまたたく間に数100や数1000の規模でオートスケールする。また、アプリケーションのImmutable設計が強制されるおかげで、大規模なバージョン切り替えやデータセンター間フェイルオーバーさえGoogle任せにできる。

引用元: Snapchatを支える技術:768台のRedisをGoogleクラウドで構築 #gcpja – Qiita.

パブリック・クラウドからプライベート・クラウドへ: なぜ移行するのか

どのような場合にプライベート・クラウドを検討すべきか

パブリック・クラウドからプライベート・クラウドへ切り換えることで、組織にメリットがもたらされるシナリオを以下に記載します。
シナリオ 1: 急速な成長

買収、合併、市場の変化などにより、中小企業が急速に大規模な組織へと成長する場合があります。このような組織は、プライベート・クラウドを使用することにより、新たに拡張されたネットワークやインフラストラクチャーを制御することができます。
シナリオ 2: 契約の解除

パブリック・クラウド・サービスがサービスの提供を取りやめる場合や、サービスの停止が非常に多い他のパブリック・クラウド・プロバイダーに買収された場合など、組織はパブリック・クラウド・サービスの契約を解除せざるを得ない場合があります。プライベート・クラウドを使用することにより、組織は内部ユーザーにクラウド・サービスを提供し続けることができます。
シナリオ 3: 新しい技術

組織は、パブリック・クラウド・サービスにはない新しいハイパーバイザー技術をテスト、インストール、デプロイしたい場合があります。プライベート・クラウドを使用することにより、組織は仮想サーバー上でのパブリック・クラウド・プロバイダーの制約を超えることができます。
シナリオ 4: フェイルオーバー計画

組織は、データ・センターのフェイルオーバーやスケーラビリティーに関して、パブリック・クラウド・プロバイダーが使用しているアルゴリズムよりも効果的なアルゴリズムをテストしたい場合がありますが、クラウド・プロバイダーのアルゴリズムをテストすることは許可されていません。プライベート・クラウドでは、組織はフェイルオーバー・アルゴリズムを制御することができます。
シナリオ 5: しきい値レベル

組織は、パブリック・クラウド・プロバイダーが交渉する意思を持たないしきい値レベルをテストしたい場合があります。例えば、パブリック SaaS プロバイダーは、SaaS 契約者としての組織と、ユーザーしきい値レベル、データ・リクエストしきい値レベル、リソースしきい値レベルの変更に関して交渉することはありません。またパブリック PaaS プロバイダーは、PaaS 開発者としての組織と、マルチスレッドしきい値の変更に関して交渉することはありません。プライベート・クラウドを使用することにより、組織はしきい値レベルの設定を制御することができます。
シナリオ 6: コンプライアンス要件

組織はインフラストラクチャーの構成、およびコンプライアンスに関し、特定の要件を満たさなければなりません。プライベート・クラウドを使用することにより、大規模な金融機関や連邦政府機関はそれぞれに対する要件を満たすことができます。
シナリオ 7: SLA 管理

組織は、SLA 同士の直接的な関係および間接的な関係についての管理を、もっとわかりやすいものにして、不必要な SLA を排除したい場合があります。プライベート・クラウドを使用することにより、組織は SLA 同士の関係を把握しやすくなります。パブリック・クラウドの契約者としての組織は、そうした関係を見たり利用したりすることはできません。
シナリオ 8: データ分析

組織は、データを分析して有用な情報を得たい場合があります。

引用元: パブリック・クラウドからプライベート・クラウドへ: なぜ移行するのか.