BLOG

AWSのサーバー移行について解説

2020/11/30

最近は、セキュリティや管理の面でレンタルサーバーからAWSに移行するという案件が増えてきています。
BRISKでもAWSを使った案件が多くなり、私も2か月程前から担当する事になりました。

毎回AWSが未知すぎて、おっかなびっくりで作業しています。
この状態から脱却したく、AWSの概要とつまずいたところをまとめてみました。

【目次】

  1. AWSとは
    1. クラウドサービスとは
    2. EC2を使う方法
    3. S3を使う方法
    4. EC2とS3の比較
  2. つまずいたポイント
    1. パーミッションについて
    2. httpとhttpsの混在
    3. 「このページにアクセスする権限がありません。」
  3. まとめ

AWSとは

AWSはAmazon Web Service の略で、その名の通りAmazonが提供しているクラウドサービスです。

クラウドサービスとは

クラウドサービス広義で、サーバーやネットワークなどのインフラを提供するサービスです。クラウドサービスを利用しない場合、サーバーやネットワーク機器を自前で用意する必要があります。この運用形態を
オンプレミスといいます。

オンプレミスとクラウドサービスをいくつかの項目で比較したものを以下にまとめてみました。

表1 オンプレミスとクラウドサービスの比較

項目 オンプレミス クラウドサービス
機材 自前で用意しなければならない 借りるだけなので、すぐ使える
障害対策 すぐ対応できるが、予備の機材を用意するなどコストがかかる 復旧を待つしかできない
保守 日々の保守運用業務、古くなった場合機材の交換が必要 必要なし
料金 初期費用が高額 従量制

他にもサーバーの選択肢として、VPSレンタルサーバーが挙げられます。

VPSは、原則1つの物理サーバの中に、複数の仮想サーバを構築してユーザーがその仮想サーバーを利用するサービスです。
レンタルサーバーは、サーバを複数の利用者が共同で使用する形のサーバーです。

レンタルサーバーは、他のサーバーとの影響が出る可能性がありますが、小規模かつ安価にサーバーを利用することができます。
VPSはレンタルサーバーとクラウドサービスの中間のようなサービスです。
自由度はレンタルサーバーを上回りますが、保守や設定など自分で行う必要があるので、専門的な知識を必要とします。

様々な観点から、案件にあったサーバーを吟味する必要がありますね。

AWSが提供しているサービスは100種類以上ありますが、今回はサーバーを構築する中でも
・Amazon EC2
・Amazon S3
を概要を紹介したいと思います。

EC2を使う方法

Amazon EC2は必要に応じてスペックを変更できる仮想サーバーを作成・利用できるサービスです。
EC2で作成した仮想サーバーのことを「EC2インスタンス」といいます。
EC2インスタンスを作成し、Apache HTTP ServerなどのWebサーバーソフトをインストールすることによってWebサーバーとして利用することができます。AMIというひな形により、EC2インスタンスで利用するOSを選ぶことができます。

サーバーはコンピュータ自体が特別なのではなく、コンピュータにWebサーバーソフトがインストールされているから、サーバーとして扱われるのですね。勘違いしてました。

WordPressなどのブログサーバーとして利用するには、
・データベースソフト(MySQLなど)
・プログラム実行ソフト、それに付随するライブラリ(WordPressの場合PHP)
をインストールして、設定する必要があります。

S3を使う方法

Amazon Simple Storage Service(S3)は、オンラインストレージかつ静的なコンテンツを配信できるサービスです。アップデートしたファイルを永続的に保存し、好きなときに取り出すことができます。ファイルを置いている場所を「S3バケット」といいます。

・S3バケットの「Static website hosting」という機能を有効にする
・匿名アクセスを有効にする
以上2点を満たすことで、Webサーバーとして利用することができます。

EC2とS3の比較

EC2とS3を比較して、表でまとめてみました。

表2 EC2とS3の比較

項目 EC2 S3
パフォーマンス 選ぶ仮想サーバー次第 高い
信頼性 構成次第 可用性99.999%
耐久性99.999999999%
プログラムの実行 できる できない
管理の必要 すべて自分で管理する必要がある 必要なし

やはり大きな違いはWebサーバー上でプログラムを動かせるかどうかですね。
静的なサイトならS3で十分でないかと思いますが、WorePressの移行となるとEC2が選択肢と上げられるのではないでしょうか。

つまずいたポイント

ここからは既存のWordPressをAWSの環境に移行した際に、つまずいたことを紹介していきます。

パーミッションについて

・FTP上でフォルダを作れない、ファイルをアップできない
・Tera Termのコマンドが実行できない

こんなことが多々あります。その原因はほとんどパーミッションです。
パーミッションについては、こちらの記事が参考になるのでぜひ読んでみてください。

【パーミッションってなに?】意味と実践的な変更手順をご紹介!

解決法

上の記事に書いている通り、変更できるユーザーに変えましょう。

また移行作業が完了したら、WordPressのディレクトリを

上記のコマンドで、apacheをユーザーにしましょう。
FTPにファイルを直接アップロードする可能性がある場合は、変更したユーザーとapacheを同じグループにする等、対応してください。

メディアのアップロードやプラグインが正常に動かない場合があるため、変更する必要があります。

上のコマンドが実行できなかったときは、コマンドの先頭にsudoを追加しましょう。

sudo [オプション] [実行するコマンド]
スーパーユーザー(rootユーザー)の権限が必要なコマンドを実行する

スーパーユーザーとは
ユーザーには権限が与えられていて、できることの制限があります。
スーパーユーザーとは制限がない何でもできるユーザーです。なので、消してはいけない重要なファイルも消せたりできるのでsudoコマンドを使用する際には注意が必要ですね。

他によく使ったコマンドをいくつか紹介します。

cd [オプション] [ディレクトリ]
ディレクトリを移動する

pwd [オプション]
現在いるディレクトリを表示する

ls [オプション]
ファイルやディレクトリの情報を表示する

mkdir [オプション] [ディレクトリ]
ディレクトリを作成する

httpとhttpsの混在

ファイルとDBをAWSのサーバーにアップしたけど、レイアウトが崩れていてエラーが起こっている…そんな状態になったことがありませんか。具体的にはこんなエラーです。

Mixed Content: The page at ‘https://サイトのURL/’ was loaded over HTTPS, but requested an insecure script ‘http://サイトのURL/css/style.css’. This request has been blocked; the content must be served over HTTPS.

HTTPSはHTTP通信を暗号化したものです。ユーザーとウェブサーバーの接続をSSLまたはTLSで暗号化し、データを安全に受け渡すことができます。
そのHTTPSページ内にHTTPで送られているコンテンツが含まれている状態混在コンテンツと呼びます。

混在コンテンツには受動的な混在コンテンツと能動的な混在コンテンツがあります。

受動的な混在コンテンツ
受動的な混在コンテンツは、HTTPSページの中でHTTP通信で送信されるコンテンツです。
具体的にはHTTPSページ内のHTTP通信で送られる<img>、<audio>、<video>、<object>のことです。

能動的な混在コンテンツ
能動的な混在コンテンツは、そのHTTPSページのすべて、またはDOMの一部にアクセスできるコンテンツです。このタイプの混在コンテンツはHTTPSページの動作を変更することができ、ユーザから機密情報を窃取することも可能です。

今回、CSSやJavaScriptを読み込む<link>、<link>がHTTP通信になっていました。これらは能動的な混在コンテンツに当たります。
閲覧しているページに混在コンテンツが含まれている場合、consoleに警告が表示されます。さらに混在コンテンツが能動的な混在コンテンツだった場合、デフォルトでブロックされるようになっています。
なのでCSSやJavaScriptが読み込まれず、レイアウトがおかしくなっていたのですね。

簡単にまとめるとページ内にhttpsとhttpが混在していてエラーになっていました。

Search Replace DBなどを使用しDBのドメインを置換したのに、どうしてだろうと悩みました。

解決法

wp-config.phpに

に追加します。

$_SERVERはPHPのスーパーグローバル変数で、サーバー情報などを取得できます。
$_SERVER[‘HTTP_X_FORWARDED_PROTO’]でサーバーのX-Forwarded-Proto(XFP)ヘッダーを取得しています。

X-Forwarded-Protoヘッダーとは、プロキシまたはロードバランサーへ接続するのに使っていたクライアントのプロトコル(HTTPまたは HTTPS)を特定することができます。
つまりユーザーがどの通信を行っていたか把握できるのですね。

AWSはSSL通信を行う方法が2つあります。
・EC2インスタンスに証明書をインストールする方法
・ロードバランサーやCloudFrontを使う方法

今回は2つめの
・ロードバランサーやCloudFrontを使う方法
でSSL化を行っていて、このロードバランサーの影響で混在コンテンツが含まれてしまいました。

まず、ロードバランサーは何かというとEC2の前に配置し、複数のEC2インスタンスに処理を振り分けて負担を分散する装置です。

ユーザーからロードバランサー間はSSL化されているのですが、ロードバランサーからEC2インスタンス間は暗号化されていません。つまりHTTP通信です。なので$_SERVER[‘HTTPS’]に値が入らず、PHPはこのページはHTTP通信を行っているのだなと認識します。
それでCSSやJavaScriptのリンクがHTTPになり、混在コンテンツが生じてしまうのですね。

それを解決するために$_SERVER[‘HTTP_X_FORWARDED_PROTO’]、つまりユーザーとロードバランサー間がHTTPS通信を行っていたら、

と指定することで、PHP側にもこのページがHTTPS通信ということを識別させていると思います。

下記のブログが参考になりましたので、貼っておきます。

[AWS] AWS 上の WordPress が HTTPS で正常に表示されない場合の対処

「このページにアクセスする権限がありません。」

サイトもちゃんと表示され、管理画面にログインしようとしたときに、

「このページにアクセスする権限がありません。」

が表示されたことはありませんか。

ユーザー名、パスワードもあっているしなぜだろうとなりました。

解決法

それは先ほどwp-config.phpに追加した

の位置が原因でした。
下記のコードより、下に書いていたら「このページにアクセスする権限がありません。」が表示されるようです。

まずWordPressのデフォルトのコメントで

と書いてますので、このコメントより前に書いておくのが安全ですね。

また、データベースの接頭辞を変更したときにも表示されるようです。
wp-config.phpの下記の部分ですね。

DBのテーブル名、フィールドの値で接頭辞が使われています。
なので接頭辞を変更する際は、Search Replace DBなど使用して新しい接頭辞に置換するのがいいですね。

まとめ

一応、BRISKで移行作業はドキュメント化されています。
でも一人で作業していると面白いほどつまずくので、今回まとめてみました。

つまずいた原因の8割ぐらいはパーミッションについてでした…。記事を読んで理解を深めようと思います。

【パーミッションってなに?】意味と実践的な変更手順をご紹介!

AWSがわからない状態と概要をだいたい知っている状態では、作業するときの負担も減るので少しずつ理解していきたいですね。

同じくサーバー移行に苦労している人の助けになれば幸いです。