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 入りはしたかったけど、条件はさほど変わらないはずなので現場のエンジニアの方、とくに日々運用でインシデント調査をしているエンジニアの方は強いですね。

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

新年明けましておめでとうございます。

2023年、スタートですね。2023年に負けず劣らず良い年になると良いなと思います。

仕事部屋の PC モニターの下に Amazon Echo Show 5インチが置いてある。

何かチラチラと視界に入ってくるなと思いながらじっと見ていたら・・・。

鼓動のように左右にチラついていた・・・・・・。

エポスカードのサイト上ではできると書いてある。

Android スマホの Google Pay 上では登録されている。そのうえで、「非接触型決済用に設定」というリンクをクリックしてセキュリティコードを入れると発行会社に蹴られた。と言われる。

なんだかもうわからないので、エポスカードのヘルプデスクに連絡したところ、「お客さまのカードが Google Pay で登録されていない。」と言われる始末・・・。

いや、めっちゃ目の前に登録済みのカードとして存在してますが。

ということで、詳細に調べてもらっている。

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

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

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

中のデータ？

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

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