AWSのSolutions Architect(SA)をやっていますと、AWSのさまざまなことを学ぶ機会があります。学ぶと、どこかで使ってみたくなるものです。最近は製品開発そのものはしなくなったのですが、身近に触れられるITインフラといえば、この koemu.com のブログを動かす基盤です。
正直、ブログを運営するだけなら、専門のサービスを頼れば技術面での管理の手離れはとても良いです。それを踏まえて、Wordpressを使って自分自身のブログを私用で動かし続けるのは、ほぼ趣味の領域とも言えます。ということで、趣味のAWSと題して、このブログのアーキテクチャを紹介する記事を書いてみることにしました。
まずはアーキテクチャ図
とりあえずご覧いただきました。ITインフラの構築・運用をされている方だと、あれやこれやとコメントが出てくるのではと想像します。僕はそういうのが大好きで、4合瓶を前にしてあーでもないこうでもないとホワイトボーディングをしたいくらいです。
アーキテクチャの大方針として2つ立てています。「コスト優先」、そして「仕組みを使って効果的に衛る」、これだけです。趣味ということもあり、商用サービスではなかなかやらないこともやっています。
コスト優先
koemu.com は、趣味で使うこともあり、とにかくコスト優先で作っています。最適化の域を越えているところもあり、商用ではそのまま真似はできない点はご理解ください。
ポイントは3つあります
- 主に東京ではなくオレゴンリージョンを使用
- 可用性の優先度を下げ障害時の回復の余地を残す
- T系インスタンスとスポットインスタンスでさらにコストを減らす
1つ目、オレゴンリージョンを主に使用している点です。Amazon EC2の価格表をご覧いただくとわかるのですが、例えば m5.large インスタンスの価格を米国のリージョン(オレゴンやノースバージニア)と東京リージョンで比較すると、30%ほど米国のリージョンの方が安い(2022/07現在 $0.096/h:$0.124/h)ことがわかります。光の速度の問題を指摘される方がいるかもしれませんが、Amazon CloudFrontを使ってページをキャッシュしてしまえばWordpressのコンテンツの提供には現実的にはほぼ差し障りはないことがわかっていたため、このようにしました。Amazon CloudFront自体も1TB/月までの転送量が無料でして、僕の使い方だと課金されるまでは行きません。とはいえ、Amazon CloudFrontがなかったとしても、このブログ程度なら太平洋を越える程度で問題になるレイテンシにはならないと考えています。
2つ目、可用性の優先度を下げ障害時の回復の余地を残しました。ベストプラクティスに則って考えると、1つのAvaliability Zone(AZ)のみで動かすのは可用性の観点では課題があります。ただ、koemu.com は趣味のブログで商用サービスを提供しているわけではないので、もし落ちたら「ごめんなさい」で済む問題です。また、Amazon EC2のインスタンスはAMIで構成のバックアップ、およびデータはAmazon S3に日次バックアップ、さらにAmazon RDSでも日次のスナップショットによるバックアップを施しています。万が一の場合は、これらのバックアップデータから最大1日前の状態まで戻すことができます。
3つ目、T系インスタンスとスポットインスタンスでさらにコストを減らしています。こえむさん、「バーストパフォーマンス(T系)インスタンスの特徴を理解して上手に利用しよう – AWS Startup ブログ」って記事を書いてましたよね、って言われそうです。そうなんです、この「特徴」を活かして t4g.micro インスタンスを選択しています。Wordpressが動いているAmazon EC2インスタンス、すなわちオリジンサーバは、Amazon CloudFrontに加え内部でWordpress自体のキャッシュも動かしていることもあり、ほとんどCPUリソースを消費しません。Amazon RDSも同様に db.t4g.micro を使用していますが、CPUクレジットも消費せず、またDBMSへの接続数も10接続行くことさえほぼありません。下記のチャートはオリジンサーバのCPUクレジットの推移ですが、ご覧のとおりほぼ消費しておりません。
また、Graviton 2というArm系CPUを使ったインスタンスを利用することで、コストパフォーマンスを上げている点もちょっとしたポイントです。極め付けは、オリジンサーバは課金体系にスポットインスタンスを選択しています。これは使用されていないキャパシティを最大90%引きの料金で利用できるものです。ただし、使用開始時に定義した予算上限を超えると2分の猶予を持ってシャットダウンとなります。商用で使われる方は、ドキュメントに記述されている特性を理解してから利用の判断をしていただくと良いかと思います。
ちょっと閑散としすぎてもうちょっとアクセスが来るような記事を書かないとな、とここまで書いて思いました。
仕組みを使って効果的に衛る
どうやってITインフラを衛るのかを考え施すことは大切です。趣味ですからバランスが必要ですが、蔑ろにして良いことにはなりません。そこで、クラウドサービスを使っていることを最大限に活かし、できる範囲でシステムを衛るようにしました。
こちらも3つのポイントを説明します。
- 外部からの直接の通信はAmazon CloudFront経由のみ
- AWS Control Towerを活用してITインフラの堅牢化を推進する
- Amazon EC2インスタンスも継続して衛る
1つ目、外部からの直接の通信はAmazon CloudFront経由のみとなっています。オリジンサーバは、セキュリティグループのマネージドプレフィックスリストを使いAmazon CloudFrontとのみ外部の通信を許しています。その上で、このブログを読んでくださる方はAmazon CloudFrontからこのページの中身が配信されてくるようになっています。そのため、オリジンサーバに不用意な通信が行われる可能性を大きく下げることができています。コンソールに入るときも、SSHは使わずにSession Managerを使っています。IAM アクセスキーはどうしているの？という質問がありそうですが、その答えは次に。
2つ目、AWS Control Towerを活用してITインフラの堅牢化を推進しています。AWS Control Towerそのものの説明をするととても長くなるので、詳細な説明は「スタートアップにおけるマルチアカウントの考え方と AWS Control Tower のすゝめ – AWS Startup ブログ」に譲ります。ここでは、特にAWS SSOによるシングルサインオンとそこで使える一時的なIAM アクセスキーを用いたAWS CLIの利用、AWS Configによる設定の評価と監視、そしてAWS CloudTrail/Amazon GuardDutyによるアカウント内での行動の証跡の監視を実施しています。なお、シングルサインオンで使っているIDプロバイダー側も多要素認証(MFA)を有効にして利用しています。
3つ目、Amazon EC2インスタンスも継続して衛っています。そのために、Amazon Inspectorを使って脆弱性の管理、AWS Systems ManagerのPatch Managerを使って継続的なパッチの適用をおこなっています。皆さんが日々利用されているMac/Windowsも定期的かつ自動的にパッチが当たるように、やはりLinuxが動いているAmazon EC2も同様かそれ以上に管理を施すようにしています。
おまけですが、意図しないコスト高を事前に検知しています。これはITインフラというより、お財布を衛っております。週次の利用額レポートに始まり、当月の予算が100％に行く目処が立ったとき、当月の予算を使い果たしたとき、そして予算を大幅に越えた時に通知が飛ぶようになっています。この管理が行えるAWS Budgetsは商用サービスでも予算管理の役に立てられます。ちなみに、現状ですと利用料はここ数ヶ月は$40/月くらいで推移しています(スポットインスタンスを使っているので今後変動の可能性あり)。
まとめ
ここまで、趣味のAWSと称しまして、このブログのアーキテクチャを紹介しました。「コスト優先」、そして「仕組みを使って効果的に衛る」の2章に分けて書きましたが、ここで計算機資源のために支払ったコストの割に、システムを衛るためには特別なコストをかけなくても始められることがいろいろあることを知っていただけたかと思います。これがクラウドの良さだなと、お客さまにご案内するときも、そして自分で使うときも深く感じています。
仕事で開発や運用を行なっていると、少なからずプレッシャーはあるかと思います。そういうのを一旦離れて、コンピューターって楽しいんだな、ってのを再確認するように楽しんでまいりましょう。