• TOP
  • BLOG
  • Movable TypeとAWSを利用したセキュアで高可用性なコンテンツ配信について
3rd Focus Blog 最近のMovable Typeでの活用方法や取り組みや、3rdfocusで取り扱っているプラグインの活用方法をご紹介していきます。
2018年10月11日 インフラ

Movable TypeとAWSを利用したセキュアで高可用性なコンテンツ配信について

このエントリーをはてなブックマークに追加

3rdFocusのブログでは初めまして、株式会社COLSIS(コルシス)の永谷ことonagataniです。

COLSISではエンジニアとして勤務しており主にインフラとサーバーサイドを担当しています。そこで今回はMTとAWSを利用したサーバ構成について簡単にご紹介させて頂きます。

前提条件

  • Firewall:AWSのセキュリティグループでしっかりと設定する。基本的には80/443以外は指定されたIPにのみ許可する(特にSSHポート)
  • バックアップ:スナップショットなどは適切に取得している前提です
  • コンテンツ:今回扱うコンテンツはMTから静的に出力されたコンテンツを前提とします。(EC2を利用している構成では動的なコンテンツも設置可能です)
  • EFS:EFSを絡めた話はしません(また今度)
  • Docker:Dockerなどのお話はしません(また今度)

最小のサーバ構成

ec2.png
  • Webサーバ:Apache/Nginx
  • DB:MySQL
  • CMS:Movable Type
  • PSGIサーバ:Starman

はい、とりたてて特筆するところはございません。サーバ自体は自分が開発しているIZANAMIで自動的に構築する事も可能です。この構成でのデメリットは以下のような感じかなと思います。

  • Firewall:AWSのセキュリティグループがあるとはいえ、CMSサーバが外部からアクセス可能
  • スパイク対策:MTは静的に出力しているので基本的に問題ないとはいえYahoo砲などで耐えられるかは疑問
  • DB:DBサーバが分離されていない
  • DR/BCP:1台構成なのでサーバダウンした場合にサイトが停止する
  • SSL:常時SSLの場合は10分の1程度まで処理速度が下がる

正直なところ一般的なサイトは上記構成でもそこそこ運用できると思いますが、セキュリティ・高可用性ともにちょっと心配ですね。(AWSも基本的にMultiAZを推奨していますしね)

セキュリティに考慮したサーバ構成

web-cms-rds.png

サーバ内の構成はほぼ変わりませんが、以下を変更しています

  • DBサーバをRDSとして分離
  • ALB(ロードバランサー)を追加しWEB/CMSサーバが直接外部にさらされないように配慮
  • ALBにWAFを取り入れることでSQLインジェクションやXSSからサイトを保護
  • ALBのSSLターミネーションを利用する事でSSLの暗号処理をALBに任せて(オフロードし)EC2の負荷に配慮。

だいぶ良くなりましたね。ALBとWAFでセキュリティにも対応し、DBをRDSとして外出することで情報漏えいリスクも少し下がったかと思います。とはいえまだ以下の懸念点があります。

  • Firewall:AWSのセキュリティグループがあるとはいえ、CMSサーバが外部からアクセス可能
  • スパイク対策:MTは静的に出力しているので基本的に問題ないとはいえYahoo砲などで耐えられるかは疑問
  • DR/BCP:1台構成なのでサーバダウンした場合にサイトが停止する

冗長性を考慮したサーバ構成

rsync.png

ALB配下にWebサーバ2台を冗長化して設置し、DBサーバもMultiAZで分離しています。CMSサーバを分離した事でCMSサーバへのアクセスをIPで完全に遮断できるようになりました。なお、サーバが増えましたがawslogsを利用することでCloudwatchにログを集約する事が可能です。

CMSサーバとWebサーバを分離したので、CMSサーバから静的に出力したコンテンツをWebサーバに設置しないといけません、今回は弊社商品であるSmartSync Packを利用しています。要はCMSサーバからrsync等でコンテンツを複数サーバへコピーしています。この構成で基本的には問題なさそうですが以下がちょっと気になります。

  • スパイク対策:オートスケールしていないのでまだ心配です
  • セキュリティ対策:ネットワークをもう少しどうにかできそう

ほぼ全てを網羅したサーバ構成

cloudfront.png

ここでCloudFront(CDN)を投入します。これによりオリジンサーバ(Webサーバ)への負荷がなくなった上にCloudFrontのおかげでスパイクアクセス、セキュリティともに向上が見込めます(動的コンテンツがなければオートスケールは必要ありません)。ネットワークも見直しを行いWebサーバはElasticIPを付与せずに外部から見えない場所に設置します。この場合サーバから外部にアクセスできなくなるためAWSのマネージドNATゲートウェイを利用します(CMSサーバをNATインスタンスとして利用する事も可能)。CMSサーバもALB下に配置する事で安心感が向上されました。

とはいえ、若干の疑問が残ります

  • CMSサーバは冗長化しなくていいの?:もちろん実施したほうがよいですが、頻繁にコンテンツ更新がなければこの構成で問題ないでしょう。とはいえEFSを利用した冗長化は次回あたりにお話します

お手軽サーバ構成

s3.png

準サーバレスといった感じの構成になります。CloudFrontとS3でのコンテンツ配信なのでセキュリティも安心ですしスパイクがあっても大丈夫です。なお、S3への転送とCloudFrontのキャッシュ削除には自分が開発しているMT-AWSUtilsプラグインを利用しています。この状態でもほぼ完璧な構成ですが少し注意が必要です。

  • MTを動かすCMSサーバは必要。IPでアクセス元を制限する事
  • S3のリダイレクトの制限などがあるので柔軟な運用をしたい場合には不向き
  • 問い合わせフォームなど動的なコンテンツはS3では動かない

簡単に説明しましたが如何でしたでしょうか。もうちょっと細かいところが知りたい方もいるかと思いますが、また記事に書くつもりなのでしばらくお待ちくださいませ。

ということで、セキュアで高可用性なサイト構築はCOLSISまでご連絡ださいませ。

この記事の筆者
onagatani
COLSISのエンジニア 永谷です。

カテゴリー