Articles in AWS

Movable Type を題材にして AWS アーキテクチャ設計を考えてみるシリーズ第5段です。

Movable Type は静的出力（スタティック・パブリッシング）をデフォルトとする CMS です。つまり、HTML などのコンテンツは実ファイルとして生成されます。こうした特徴から、生成されたコンテンツだけをウェブサーバーで公開することができるため、アプリケーションへの接続を一般利用者に公開しなくても良い点がセキュリティ上のメリットとして存在します。

AWS を利用する場合は、上記のメリットに加えてそもそもサーバーを1台減らせるメリットも存在します。

2023年6月21日付けで、インプレスさんから「徹底攻略 AWS認定 クラウドプラクティショナー教科書」という書籍を出版しました。

いわゆる黒本と呼ばれるインプレスさんの徹底攻略教科書シリースの AWS クラウドプラクティショナー認定向けの解説本です。

Movable Type を題材にして AWS アーキテクチャ設計を考えてみるシリーズ第4段は、高可用性について考えます。

Movable Type では、可用性を考慮すべきものとして Web サーバ、DB サーバー、App サーバーが考えられます。

サーバーの分離により、データストレージは EFS になっていれば、データ自体の可用性を考慮する必要はなくなっています。そして、そもそも可用性を考えるなら、冗長化が必要になるので必然的に EFS を採用することになると思います。

第2回では、1台の EC2 インスタンスではなくサーバーを役割に応じて分離することことでマネージドサービスを活用することや、1台のサーバーの性能を最大限発揮させることを実現しました。

第3回の今回は、EC2 インスタンスを使い捨てにすることで、より柔軟なアーキテクチャにしていきます。

突如始まったシリーズ第二弾、前回は1台の EC2 インスタンスですべてをまかなう All-In-One な構成を考えていきましたが、実際のプロダクション環境では採用するべきではない点についても触れています。

今回は、EC2 インスタンスの負荷を軽減させることをメインに考えてみます。

Movable Type を題材にして AWS のアーキテクチャ設計を解説するシリーズを突如開幕。

AWS アカウントの作り方などはこちらからどうぞ。

あくまでも、AWS アーキテクチャ設計をテーマとしているので、Movable Type の使い方とかプラグインでもっとこう。とかそういう話はありません。そういった話は公式サイトを見てね。

Movable Type の部分を別のアプリケーションなんかに置き換えて考えてみると良き。

AWS の認定試験は、FOUNDATIONAL、ASSOCIATE、PROFESSION、専門知識の4カテゴリ12個あります。

本日、専門知識以外の最後に残していた AWS Certified DevOps Engineer - Professional を受験して合格したよ。

AWS Top Engineer 限定イベントの「セキュリティインシデント調査ワークショップ」に弊社 Top Engineer や 他のAAI と併せて4名で参加してみた。

結果としては、最初の頃はゲームディのプラットフォームへのアクセス負荷でなかなかサイトにアクセスができず進まない時間があった中でも、そこそこ課題を解決できたのかな。といったかんじ。36チーム中20位。Top 10 入りはしたかったけど、条件はさほど変わらないはずなので現場のエンジニアの方、とくに日々運用でインシデント調査をしているエンジニアの方は強いですね。

さらなる精進が必要です。

普段はお仕事で Rocket.Chat を利用しているわけですが、基本的にはスポットインスタンスを利用しています。

スポットインスタンスである以上は避けられないのがスポットインスタンスの中断なわけでして、スポットインスタンスの料金履歴を見ながら比較的料金が安定しているインスタンスタイプとアベイラビリティゾーンを選んでいたわけです。

それでも起きるときには起きるものです。久しぶりにインタラプトが発生してスポットインスタンスが逝きました。

中のデータ？

もちろん、一緒に逝きました。バッドプラクティスを実現していた結果です。

これでは良くない。ということで、きちんと対策を取っていきます。（この記事は大作でもあります。）

S3 には、ユーザーが任意の Key-Value データを保管できるオブジェクトメタデータという仕組みがあります。

単純なデータを格納できるので敢えてデータベースを用意しなくても済むというメリットがあります。

そして、S3 API には、オブジェクト自体を取得せずにオブジェクトの情報を取得する HeadObject という API があります。

API のリファレンスにはオブジェクトメタデータも取得できると書いてありますが、Ajax で呼び出したときには実はメタデータは取れません......。

しばらく悩んでいて、GitHub の AWS JS SDK Issues にもレポートが合ったので Watch していたのですがやっと原因がわかりました。

その昔、こんな記事を書きました。

S3 と連携して CodePipeline で EC2 Image Builder を動かす

CodePipeline を利用して Lambda を起動して EC2 Image Builder を呼んでいました。

その後、S3 から EventBridge 経由で直接いろいろなサービスを連携できるようになったので、ノーコードで Step Functions のフローにできるんじゃないか？と思いやってみた次第。

今年も新しい AWS 認定取ってきた。AWS Solution Architect - Professional です。

長年 AWS を触ってきているけど、エンタープライズ向けソリューションアーキテクト向けとも言える認定試験なので、普段は全く触ったことが無いサービス（触れる機会がない）や、大規模の設計に関する知識を問われるので勉強も大変というアレです。

AWS 認定インストラクターになってからガチで AWS を改めて学んでますけど、今回は中々の戦いでしたわ。180分フルに使ったわ・・・・・・。

特定の属性を持たない項目を洗い出してなんとかする。というシチュエーション。

必要なデータなら入れるときに弾きなさいよ。というところでもあるけれど、必須ではないけど・・・。というような場面は、まあありえるか。

EC2 Image Builder を使うと AMI のビルドをパイプライン化できるというのは、以前にも書いたけれども。

• EC2 Image Builder で MT の AMI を構築

今回は、S3 と CodePipeline を連携させて、S3 に MT のファイルをアップすると自動で AMI 作成して結果を Slack に通知してくれる仕組みを作った。

AWS ElasticBeanstalk を使ったデモ環境を作ろうと Node なでもアプリをデプロイしたところ中々動かなかったのでメモ。

サンプルアプリじゃなく、イメージをアップロードできるギャラリーサイトを作ってたのです。

コース実施が無い日程がちょうどあったので、AWS 認定試験を受けてきた。今回受験したのは次の2つ

• AWS 認定 SysOps アドミニストレーター - アソシエイト
• AWS 認定 デベロッパー - アソシエイト

結果は無事合格。得点も自分で思っていたよりも取れてた。これでアソシエイト・レベルは取ったので次はプロフェッショナル・レベルと専門知識だな。

10年前の今日、AWS 東京リージョンが爆誕しました。

東日本大震災直前のリリースで、震災後の復旧にも多大な貢献をしたのも記憶に新しいところ。

そんな記念すべき日に（多分）合わせて大阪リージョン爆誕です。
もともと、2018年に東京リージョンのバックアップ（DR対策）としてオープンしていた大阪ローカルリージョンがスタンダードリージョンにアップグレードされた感じですね。

AWS Asia Pacific (Osaka) Region Now Open to All, with Three AZs and More Services

ということで、大阪リージョンと東京リージョンを VPC ピアリング接続して速度を測ってみた。

これまでは、Movable Type AMI 版 を使っていましたが、個人無償版 + AWS な構成に変更することに。

Movable Type 環境構築の手間もあって AMI 版だったわけですが、EC2 Image Builder で AMI を作るパイプラインを作ったので、MT のアップデートに合わせて新しい AMI を作っていけばOK。

AWS EC2 Image Builder というサービスがあります。

Production Ready ないわゆるゴールデンマスターになる AMI の構築は結構手間で、実際の環境を構築してからイメージ作成をおこなう手順が必要でした。

EC2 Image Builder は、この作業を自動化してくれるのと、セットアップされた内容の検証も自動でやってくれるサービス。

朝イチのニュースで S3 が PrivateLink をサポートしたよ。っていうのがあったので、よくある話のオンプレ環境からインターネットを経由しないで S3 にアクセスする。を試してみた。

ニュースはこちら。

これまでも、S3 は、ゲートウェイ型の VPC エンドポイントをサポートしていたので、VPC 内に Proxy Server を用意してごにょごにょ。とすればできる。というストーリーで話をするのだけれども、PrivateLink で出来るようになったので不要な EC2 を立ち上げなくても良くなる。

結論から言うと、Aurora Serverless のクラスター止まらんかった。。。

正確に言うと、EC2 インスタンスが止まればそれに合わせてクラスターも停止していた。

よく分からないのは、Database Connections が 0 のときも動き続けていること。Data API で検索とかしているから外からの呼び出しが常々あるというのなら分かるけど、アクセスログを見る限りそんなこともなさげ。

このままでは効率悪いので一旦普通に戻す。

素のやつで検証しよう・・・。

このブログは、Movable Type で作っているけれども、データベースを試しに Aurora Serverless にしてみた。

パフォーマンス的には全然問題ない。あとはコスト面がどうなるのかちょっと様子を見てみたい。

なぜ、Aurora Serverless にしたのか？

AWS Amplify は、これまでちゃんと試したことがなかったので。Amplify Docs で公開されてる Vue を使ったチュートリアルをやってみた。

一言で言って、なんて簡単にサービスが作れちゃうんだ。

AWS を使い始めてはや5年以上。

個人的な使用と、前職の職場環境での利用と、Movable Type の AWS 版を色々触ることがメインで、ユーザーへの提案とか仕事ではしていなかったので認定資格は取っていなかったけれど、認定トレーナーになるためには、Solution Architect Associate が必要ということもあり試験を受けてきた。

結果としては、無事に Solution Architect Associate と Cloud Practitioner の試験に合格。めでたい。

試験内容は、来年にも更新されるらしいけど、問題の傾向をまとめておく。