You are here:--パブリック・クラウドを活用したWebホスティング

パブリック・クラウドを活用したWebホスティング

パブリック・クラウドを活用したWebホスティング

弊社、キュービットセキュリティはホームページ/ブログをPLURAサービス網と完全に分離して運営しています。
安定性とセキュリティ性重量を置いたPLURAサービス網とは異なり、私たちのホームページ/ブログはパフォーマンスに重点を置いて
パブリック・クラウドに構成しました。おおよその構成は次のとおりです。

 

状況に合わせてクラウド前スタック(IaaS、PaaS、SaaS)の両方を使用しました。

構成を順番に調べてみましょう。

1. CDN (AWS: CloudFront, Azure: CDN)
AWSエッジロケーションに位置するCDN層では、ほとんどのコンテンツをキャッシュしているが、要求時にすぐに転送します。また、この層では、WAFの層を加えて、SQLインジェクションやXSSなどの攻撃を1次フィルタリングします。
MS Azureの場合には、Akamai、Verizonなどのグローバルパートナーを通じてCDNを提供しています。
また、Webサーバからこの層までhttp圧縮して配信し、この層を通って信頼できないインターネット網を介してユーザーにデータが渡されるので、機密性のためにhttpsに変換します。
また、AWSが提供するCDNとLoad Balancer層は、従来のシステムとは異なり、トラフィックをそのまま渡してくれるので、Source確認のため、X-Forwardforなどの設定をしなくてもされます。

AWS: aws.amazon.com/cloudfront/
Azure: azure.microsoft.com/en-us/services/cdn/

 

2. Load Balancer (AWS: ELB, Azure: Load Balancer)
キャッシュされたコンテンツではなく、他の要求が入ってきた時に、Webサーバーを負荷分散します。基本は、インスタンスしたままになっているが、CloudWatchがCPUを注視している途中、使用量が80%を超える時CloudFormationをトリガーして、事前に定義されたスクリプトに従って、Webサーバーインスタンスを複製、生成し負荷分散poolに含めます。

AWS: aws.amazon.com/elasticloadbalancing/
Azure: azure.microsoft.com/en-us/services/load-balancer/

 

3. Webserver (AWS: EC2, Azure: Virtual Machines)
仮想マシン上のWebサーバーをインストールした後、ワードプレスで構築しました。
また、オートスケーリング時の複製されて生成されるマシンとのデータの不整合を防ぐために、仮想マシンの外部に存在するAWS S3にコンテンツをバックアップして同期するように設定しました。 FUSEを利用してS3をNFSのようにマウントする方法もあるが、パフォーマンスや安定性など、多くの損害を見るために、ワードプレスで提供されるプラグインを利用してS3でコンテンツを同期したいお勧めします。
さらに、ElasticBeanstalkのようにPaaSを使用すると、PHPマシンにwordpressコードのみアップロードして使用可能なの運営負担が軽減されます。私達の場合には、Webサーバー上でlogを収集するために、仮想マシンに直接WebサーバーとPHPを上げて構築しました。
ホストするページが静的なページの場合、ページをS3にアップロードするだけで、Webホスティングが可能です。この方法を使用すると、すべての管理プロセスがなくなります。

AWS: aws.amazon.com/ec2/
Azure: azure.microsoft.com/en-us/services/virtual-machines/

FUSEを利用したS3直接マウント: github.com/s3fs-fuse/s3fs-fuse/
Wordpressのプラグインを利用したS3バックアップ: wordpress.org/plugins/amazon-s3-and-cloudfront/

 

4. Database (AWS: RDS, Azure: SQL Database)
仮想マシンのインスタンスに直接DBをインストールする方法(IaaS)ではなく、管理DBを選択し(PaaS/ SaaS)しました。これはオートスケーリング、リージョン間DBの複製、自動更新、およびバックアップなどを手軽にサポートします。管理型DBの場合には、下位レイヤであるDBのOSに直接アクセスすることはできません。mysqlコマンドを使用したアクセスのみ可能です。

AWS: aws.amazon.com/rds/
Azure: azure.microsoft.com/en-us/services/sql-database/

 

5. Virtual Network (AWS: VPC, Azure: VNet)
仮想ネットワークを定義する方法は、AWSとAzureの間に類似点が多いです。ネットワーク利用可能IP数を計算する際に、従来の環境では、2つの(ネットワークアドレス、ブロードキャストアドレス)を第一方、パブリック・クラウドでは、5つの(ネットワークアドレス、ブロードキャストアドレス、ゲートウェイ、仮想DNS、予約アドレス)を第ます。
サブネットの範囲は、ベンダーによって違いがあります。 Azureの場合には、従来の方式と同様に提供する一方、AWSは制約があります。たとえば、クラスAのプライベートネットワーク(10.0.0.0/8)の場合、既存の通りなら8〜30 bitのサブネットが可能です。ただし、クラウドでは、5つのアドレスが、基本的に使用される点を勘案すれば、8〜29 bitが使用可能なサブネット範囲になります。
Azureは、実際に8〜29bitまでサブネットを許可します。 AWSの場合には、16〜28bitの範囲内でのサブネットのみを許可します。このような点からも、従来のサポートに忠実なMSと既存の型にとらわれず、新たに作っていくAWSの傾向の違いが見られるようです。

AWS: aws.amazon.com/vpc/
Azure: azure.microsoft.com/en-us/services/virtual-network/

 

6. リージョンとredundancy関連

高可用性設計のためにはredundancyの検討も重要です。
AWSの場合には、それぞれのリージョンがあり、各リージョンは再び2〜3つの利用可能な地域(AZ)を持ちます。ソウルリージョンの場合に2つのAZで構成されており、それぞれは、ソウル基準で南、北にあると言われています。リージョン間の価格差はあるが、AZ間の価格差はありません。
Azureの場合には、各地域間のペアを行わリージョンが存在します。韓国の場合Korea Central、Korea Southにそれぞれソウル、釜山にいます。 AWSの場合には、AZだけredundancyのためのコンピューティング・リソースを共有することによって配置するのが、考慮すればよいがAzureの場合には、Korea Central – Korea South間の価格差も存在します。
リージョンと関連した、より深い内容は、以下のリンクを参照してください。

この部分では、Azureが比較的良い評価を受けます。 VMを作成する際に、update domain、fault domainなどを設定することができ、コンピューティング・リソースがどこで実行されるか、まったくの可視性を提供しないAWSとは異なるAzureは、さまざまな方法で見せていた、従来の環境のサポートに優れたMSだからできることはないかします。

AWS: docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html
Azure: azure.microsoft.com/en-us/regions/

Azureでの可用性の設定: docs.microsoft.com/en-us/azure/virtual-machines/windows/manage-availability

 

References:
https://aws.amazon.com/blogs/security/
https://azure.microsoft.com/en-us/blog/

 

By |2018-07-03T10:24:11+00:00September 27th, 2017|Categories: カラム|0 Comments

About the Author: