AWSを使ってソーリーサーバを構築しました。割と便利だと思う…。

とてもお久しぶりです。
恵比寿のITベンチャーでサービス運営やっています。
仲間募集中です。ご興味ある方はTwitterなどでご連絡ください。

今回はAWSを使って、わりと便利なソーリーサーバを構築しましたというお話です。
構成は下の図のようになっています。



通信フローとしては、まずエンドユーザがELBにアクセスします。 このELBは既存のWebサービスやWebサイトをバランシングしていたものです。 諸事情によりメンテナンスしたり、ドメインを畳むことになったという話を想定しています。
そのELBに接続されていたWebサーバやアプリケーションサーバの代わりにソーリーサーバを接続します。 するとエンドユーザはソーリーサーバにアクセスしてきますよね。
ソーリーサーバはリクエストを受けたら、各ドメインに対応させたいCloudFrontへリクエストをパスします。 CloudFrontはS3のコンテンツを返すのですが、このS3に静的なソーリーページを格納しておきます。 それにより、ドメインにアクセスしてきたエンドユーザにソーリーページを見せることができます。
ポイントはソーリーサーバとCloudFrontですがやってることは簡単です。 まず、ソーリーサーバはただのNginxです。 proxy_pass を使って、特定ドメインに来たリクエストを対応するCloudFrontのドメインへパスします。 その設定は、/etc/nginx/conf.d/virtual.conf に書きました。

server {



        listen 80;



        server_name example.com;



        if ($http_x_forwarded_proto != https) {



                return 301 https://$host$request_uri;



        }



        location / {



                proxy_pass http://domain-a.sorry.example.com/;



        }



}
上記の server ディレクティブのかたまりを、ソーリーページの数だけ用意します。 １ドメイン１種類のページでよければ、3ドメインなら3つのディレクティブになります。
if文のおかげで、自動でHTTPSになります。
しかしここで一つ問題があります。 ELBごとにヘルスチェックエンドポイントが違うのです。 なのでそのままではそもそもNginxがヘルスチェックに合格せず、ELBがNginxにリクエストを渡してくれません。
それはNginxの素敵機能 empty_gif を使って解決します。 今回は /etc/nginx/nginx.conf に以下のように書きました。

http {



    （略）



    server { 



        （略）



        location / {



                 empty_gif;



                break;



        }



    （略）



    } 



    （略）



}
これにより、どんなパスへのアクセスに対しても 1ピクセルのgifイメージを生成して返します。 そのおかげで、ELBのどんなヘルスチェックパスも合格し、めでたく InService になることができます。
残りは CloudFront ですね。
CloudFrontはソーリーページごとにインスタンスを用意する必要があります。
理由はカスタムエラーページを利用したいからです。
CloudFrontのカスタムエラーページでは、特定のHTTPステータースコードの場合、任意のステータスコードに変更することができ、さらに任意のコンテンツを表示させることができます。
これを使って、全ての403アクセスを404へ変更して、ついでにソーリーページのhtmlを表示させちゃうことができます。
なんで403にするかというと、CloudFront + S3 でのコンテンツ配信方式で、ページが存在しない場合、CloudFront側が 403 Access Denied を返すからです。
これを404＋ソーリーページにすることで、どんな存在しないURLにアクセスが来ても、自分が用意した404用のhtmlが表示されることになります。
ただし、「正しいソーリーページのパス」にアクセスされると、ステータスコードは200になってしまいます。
よほどの物好きなエンドユーザ意外はそんなことしないので、気にしないことにしました。
Nginxのコンフィグの書き方でもうちょっとCloudFrontのインスタンスを減らせる気もしますが、料金体系的にデータ転送量とリクエスト数のみで、インスタンス数による固定料金はないので、管理は面倒くさいですがこれでいいかなという感じです。

あ、あと、ACMを使って無料証明書を取得してCloudFrontに登録しています。
そのために、 sorry.example.com のような、ソーリーページ専用サブドメインを用意して、 それのワイルドカード証明書をACMから発行させてもらっています。

ところで何が便利なの？
まず、ステータスコードを任意に指定できます。404とか、500とか。それから、ソーリーページにhttpsが使えます。労力の割には些細なリターンのような気もしますが…。
NginxのコンフィグはGitで管理してAnsibleなどで配布できます。
１台に全部のソーリーページについて書かなきゃいけないですが、書いてしまえば、１台をマスターサーバにして楽にスケールアウトできます。
マスターサーバのコンフィグに全てのソーリーページの設定が書かれてあるので、ドメインに対して透過的なソーリーサーバが出来上がります。
どのELBにどのサーバを突っ込んでもOKということです。

コメント

コメントを投稿

このブログの人気の投稿

オライリーのDocker本を読んだり色々な記事を読んだりしたので自分なりにまとめる（Dockerfileについて）

Docker経験値0だった私も何冊か本を読んで実際にDockerfileを見たりいじったりしてみてECSに試行錯誤でデプロイしてみたりして、ようやく少しずつ慣れてきた感が出てきました。 しかしまだまだ「バッチリできます！」というには力不足間は否めなく…いやそういう話じゃない。 折角本を読んだりネット上の先輩たちの記事を読んだりして色々覚えたのだから、それをまとめておきたいと思います。 実はもうすでに 日本語での公式なDockerfileベストプラクティス が存在するので、意味がないといえばたぶん意味はないのですが、アウトプットをして学習にいったんの区切りをつけるという意味で自己満足も兼ねて書きたいと思います。 Dockerfileについての基本的なこと 1コンテナ1プロセスを起動するつもりでDockerfileを書く 1プロセスとはつまりnginxとmod-phpによるPHPアプリケーションなら2つのコンテナを用意するということ コマンドは大文字で書く（ RUN, COPY, EXPOSE 等） #によるコメントアウトが使える FROM 文は先頭に1行だけ書く CMD 文は末尾に1行だけ書く Dockerfile についてやるべきこと・意識すべきこと DockerHub のイメージは「公式」とわかるもの以外むやみやたらに使わずできるだけ Dockerfile を読んでから利用を判断する DockerHub は Docker イメージの共有サイトだが、有象無象のコンテナイメージが登録されており、（その意図はなくても）セキュリティ的に危険なコンテナが存在する可能性は十分にある。  DockerHubが公式に提供しているNginx  など、ソフトウェアベンダ（団体）の公式イメージ以外は基本的に利用しないことで基本的なセキュリティある程度確保することができる。 構文にはshell形式とexec形式が利用できるものがあるが基本的にexec形式を利用する 例えばCMDコマンドはshell形式とexec形式を利用することができる。 shell形式は指定された文字列を /bin/sh -c に渡すことでコマンドを実行する。 その場合に、exec形式だと/bin/shに対する攻撃のような文字列の実行を回避することができる。
続きを読む

一部のユーザだけ NET::ERR_CERT_REVOKED でサイトにアクセスできない

イメージ
一部のユーザから、HTTPSのURLにアクセスできなくなったという連絡を受けました。 なんでも攻撃される恐れのあるサイトですとかなんとか…。 ブラウザのスクリーンショットをもらってみたら、こんな表示が。 Google Chromeでも同じ感じのエラーメッセージが表示されていました。（サイト名が出るので省略…） Chromeの方のエラーメッセージをよく見ると、 NET::ERR_CERT_REVOKED と書かれています。ファッ！？証明書が失効している…！？ そんな馬鹿なと思い手元でアクセスしてみたら普通に繋がる…HTTPSできてるよ？なんで？何が起こってるんだろう…。 結論を言うと、 SSL証明書業者が手違いで中間CA証明書を失効させてしまった ことにより、私たちが購入して使っている証明書が一時的に利用不可能になり、そのネガティブキャッシュをユーザが参照している 、というお話でした。 解消のための新しい中間CA証明書が公開されていたので、そちらを使って更新してみると、問題は解消されました。 ただ、自社が買っていたのはクイックSSL証明書だとばかり思っていたので、更新に失敗しまくって時間がかかりました。違うやつだった…。 SSL証明書とかドメインの周りのメンテナンスは多くても年に数回とかっていう頻度なので、いろいろ思い出すのに苦労しますね。 ていうか、そういうことあるんですね、中間証明書間違って消しちゃった！とか。 レジストラのDNSサーバダウンと合わせて、「 うちのせいじゃないんだけどご迷惑をおかけしてごめんなさい案件 」って感じで覚えておきたい…。
続きを読む

[#CentOS][#Apache] CentOS6 でApacheが起動できない

CentOS 6 で httpd を起動させようとした時のこと $ sudo /etc/init.d/httpd start httpd を起動中: httpd: bad user name apache    [ 失敗 ] なんじゃこりゃ。 ■問題 Apacheが起動できない。問題はapacheユーザ ■原因 httpd.confには ユーザ：apache グループ：apache　でhttpdを起動するようになっている。 ユーザとグループを確認してみよう… $ cat /etc/passwd | grep apache $ ユーザが居ない… $ cat /etc/group | grep apache apache:x:48: グループはある。なんでこうなってんだ？ ■対処 ユーザ「apache」を作ってグループ「apache」に入れてあげよう。 # useradd -g apache apache useradd: /etc/passwd をロックできません。後でもう一度試してください。 は？(#ﾟДﾟ) # ll /etc/*.lock -rw-------. 1 root root 5  2月 12 07:29 2013 /etc/passwd.lock -rw-------. 1 root root 5  2月 12 07:29 2013 /etc/shadow.lock これを消すか # rm /etc/passwd.lock rm: remove 通常ファイル `/etc/passwd.lock'? y # rm /etc/shadow.lock rm: remove 通常ファイル `/etc/shadow.lock'? y これでもう一度apacheをuseraddして…あれ、もしかしてロックファイルがApahceをインストール剃る前からあって、もしかしてyumのインストールシーケンスの中でユーザ作成だけ失敗してたりしてるのかな？ ということでApacheをインストールし直す方向で。 # yum remove httpd $ sudo yum install httpd httpd-devel mod_wsgi Pythonの勉強したいからmod_wsgiも入れてます。 で、yum入りました。 Transaction Summary
続きを読む