Help us understand the problem. What is going on with this article?

Jira/Confluence/BitbucketServerのフロントをCloudFrontにしてみた話

More than 1 year has passed since last update.

AWS上にAtlassian製品を立てるときに、フロントをALBにするのが普通だと思うのですが、CloudFrontにしたらどうなるかやってみたお話です。

なんでこれやったの?

CDN/CloudFront and Atlassian Server apps

Atlassianのコミュニティでやっている人がいたので、本当にこんなに効果があるのか試してみました。

構成

nginx → Jira,Confluence で動かしていたのを
CloudFront → ALB → Jira,Confluence に変更しました。

nginxは振り分けとキャッシュとIPアドレス制限しかしていなかったため無くして、CloudFront+WAFに置き換えました。

aws_atlassian_structure.png

CloudFrontの設定

Origins

  • ALB
  • S3 Bucket

基本的にALBに流しますが、一部カスタマイズ用の css js png など静的ファイルだけS3に置いています。

Behaivors

Precedence Path Pattern Origin or Origin Group Viewer Protocol Policy Forwarded Query Strings
0 /confluence/s/* ALB Redirect HTTP to HTTPS Yes
1 /confluence/download/* ALB Redirect HTTP to HTTPS Yes
2 /jira/s/* ALB Redirect HTTP to HTTPS Yes
3 /jira/secure/projectavatar* ALB Redirect HTTP to HTTPS Yes
4 /jira/secure/viewavatar* ALB Redirect HTTP to HTTPS Yes
5 /jira/download/resources/* ALB Redirect HTTP to HTTPS Yes
6 /jira/images/* ALB Redirect HTTP to HTTPS Yes
7 /bitbucket/s/* ALB Redirect HTTP to HTTPS Yes
8 /bitbucket/*/avatar.png ALB Redirect HTTP to HTTPS Yes
9 / S3 Bucket Redirect HTTP to HTTPS No
10 /static/* S3 Bucket Redirect HTTP to HTTPS No
11 favicon.ico ALB Redirect HTTP to HTTPS No
12 Default (*) ALB Redirect HTTP to HTTPS Yes

各Path Patternの設定値はCDN/CloudFront and Atlassian Server appsとだいたい一緒にしました。

効果

キャッシュヒット率

CloudFrontHits.png

1つのCloudFrontに全ツール(Jira/Confluence/BitbucketServer)をぶら下げてしまったので、各ツールのヒット率は出せないのですが、うちの環境では 12.65% になりました。低いですね。

Errorsが結構あるのは、すでに無効になっているユーザーやリポジトリに対してgit pullし続けるようなcronやjenkinsが回っているためです。

Jira: Of the 689GB traffic initiated by users browsers, 587GB has been served directly from CloudFront, leaving only 102GB needing to go back to the server (origin) ~ 85%
Confluence: Of 185GB total, 160GB has come from CloudFront, 26GB from the server ~ 86%

Path Patternも設定値も真似て作ったのですが、85%に遠く及ばないヒット率になりました。
使い方によるものはあるのでしょうが、ここはもうちょっと試行錯誤が必要そうです。

費用はそれなり

2週間で250万アクセスくらいで1ヶ月稼働させたときの費用。

Product Price/month
CloudFront $6.47
ALB $18.34
CLB $15.55
WAF $22.62

nginxをフロントに立たせてもEC2代がかかるので、同じくらい費用がかかると思います。
nginxで受けたパターンは実際にはAWS上では構築していなかったので比較はないです。

レスポンスは速くなった気がしないでもない

nginxを使っていたときも当然キャッシュしていたので、あまり変化はなかったです。
逆にCloudFrontに変更しても同じくらいのパフォーマンスは出るとも言えます。

もっと遠くの地域からなら、エッジロケーションの効果も実感できるかもしれませんが今回は試していません。

WAFのおかげで疎通確認オペレーションが楽になった

WAFのlogはKinesis Data Firehoseに流せるので、あとに続く処理を如何様にもできます。
iptablesでもlog吐いてfluentdでFirehoseに流せば同じことができますが、設定だけでこれが可能になるのは嬉しいところ。

リクエスト投げる側が困ること

IPアドレス制限をしていてリクエストを受ける側はWAFで制御すればいいのですが、リクエストを投げる側がOutboundを厳密に管理しているような場合、困ることがあります。

CloudFrontは固定のIPアドレスを持たないため、取りうる可能性があるIPアドレス帯をすべてOutboundで許可する必要があります。

CloudFront エッジサーバーの場所と IP アドレス範囲 - Amazon CloudFront

固定IPアドレスにしたければNLBを使うことになるのですが、SSLアクセラレーション機能がなかったりセキュリティグループを設定できなったりと、EC2側で対処しなければならないことが増えて微妙です。
(Global Acceleratorを使えばIP固定化できますが、まだ検証できていません)

BitbucketServerもCloudFrontの下に置くと困ること

JiraやConfluenceだけなら問題はないが、BitbucketServerも一緒に管理しようとするといくつか問題が出てきます。

sshが受けられない

CloudFrontで扱えるProtocolは http https のみ。
ALB直にアクセスしようとしても、ALBで扱えるProtocolも http https のみ。
ssh 用のCLBを別に用意する必要がある。

大きいリポジトリをcloneするときにタイムアウトする

httpsでgitを使っても問題が出てくる。
CloudFrontのtimeoutが最大60秒なので、大きいリポジトリをcloneするときタイムアウトしてしまう。
そういうときは --depth を使ってshallow cloneすればいいのだが、初見の人は必ずつまずくので運用上よくはない。

httpsでgit cloneするときのはALB直にすればいいのだが、その時点でもうCloudFrontは使わないと同義となる。
BitbucketServerはssh時のURLは指定できるが、https時のURLはBase URLから取っているため、git cloneのときだけサブドメインを変えたURLにするのは通常の手段ではできない。

Bitbucket Server config properties - Atlassian Documentation

総評

コミュニティに書かれていたような高いキャッシュヒット率を出すことはできませんでしたが、他のCloudFrontの利点(エッジロケーション、マネージドサービス、WAF)は享受できていますし、レスポンス速度が落ちていないのはいいですね。

いくつか気をつけないといけない点はありますが、使い方によって無視してもいいものなので、この構成もありだと思います。

Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
No comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
ユーザーは見つかりませんでした