AWS運用のポイント特集

公開日時:2022年10月28日 / 最終更新日時:2022年12月04日

AWSの運用について今まで気を付けてきたこと、今まで失敗したことをベースにAWS運用のポイントを記載します。

私自身も何度も見返して AWS を運用する上で忘れないようにしたいと思います。

視点としては現場で手を動かしているメンバーの視点です。

AWS 失敗事例で検索するといろいろな事例が出てきますが、現場のメンバーの視点ではなく「だから弊社に御社の AWS 運用管理を任せてください!」という営業戦略に則った架空の失敗事例が多いような気がします(笑)

 

EC2

EC2インスタンスの運用についてポイントを解説します。

「再起動しない」の「有効化」のチェック

AWS管理コンソールからAMIを取得する際に「再起動しない」「有効化」にチェックを入れ忘れるとEC2インスタンスが再起動してしまいます。

これにチェックを入れるのを忘れてしまうと、いきなり本番環境のDBが再起動して業務が停止または遅延するという障害が発生します。

 

 

AWS のメンテナンスで EC2 や RDS がリブートされる

EC2 や RDS は一度構築したら永遠に起動し続けるわけではありません。

AWS側で定期的にメンテナンスを実施しています。

EC2 ダッシュボードのイベントに「system-reboot」「instance-reboot」などと記載があります。

こちらを確認することで「イベントタイプ」「開始時刻」「期限」を確認することが出来ます。

 

この AWS メンテナンスに気が付かないと予期せぬタイミングでいきなり EC2 インスタンスや RDS がリブートされることになります。

 

 

 

メンテナンス関連で EC2 インスタンスのリブートを実施する際は「停止」→「起動」が必要なのか確認する

EC2 インスタンスのメンテナンスで EC2 インスタンスをリブートする際は、単純に「再起動」でいいのか、「停止」→「起動」の処理が必要なのか確認しましょう。

ここでのポイントは「system-reboot」「instance-reboot」かどうかという点です。

 

 

 

後は「イベント」を確認してイベントに残っていないかどうかを確認することも重要です。

 

 

EC2 インスタンスを「停止」→「起動」後にパブリックIPが変わっていることがある

Elastic IP を利用していれば大丈夫ですが、Elastic IP ではなくパブリック IP を割り当てているだけの場合は、EC2 インスタンスの「停止」→「起動」でパブリック IP が変わってしまいます。

 

しかも ELB などを経由せずに直接 Route53 などで名前解決の設定をしている場合は接続できなくなるので Route53 の再設定も必要になります。

 

 

インスタンスタイプのファミリーを変更してスペックアップできない場合がある

例えば t2.micro からメモリの搭載が多い他のインスタンスタイプのファミリーに変更したくなることがあります。

しかしインスタンスタイプのファミリーを変更できることもあればできないこともあります。

実際に計画を立てて、いざインスタンスタイプのファミリーを変えようとしたらエラーが出たり、変更できたけど EC2 インスタンスが起動しない、EC2 インスタンスは起動しているけどログインできないなどの現象が発生することがあります。

事前にインスタンスタイプのファミリーを変更できるのか検証するなどの対応が必要になります。

 

 

I/O に問題があるからインスタンスタイプをアップグレードする?

いまだに EC2 インスタンスに DB を載せて運用している企業は多々あります。

そこそこの企業でも Aurora Serverless で運用しているケースは多くないです。

オンプレ(もしくは VMware)からEC2にマイグレーションしてそのまま使っているケースは多いです。

DB を運用していると「I/O にボトルネックがありそうだからインスタンスタイプを上げてよ」と言われることがあります。

しかし EBS の場合は「オンライン」で「ボリュームタイプ」を gp2 から gp3 や io1、io2 に変更することが出来ます。

2022年11月現在、io2 は最新のボリュームタイプですが、IOPS も細かく設定できます。

しかも IOPS を上げるだけでなく下げることも出来ます。(ここ重要です)

ボリュームのサイズは一度上げたら下げられませんが、IOPS は下げることもできます。(簡単です)

なので、DB を運用していて I/O に問題がありそうならボリュームタイプの変更を提案しましょう。

 

 

 

 

RDS

RDS も様々なトラップがあります。しかも RDS は EC2 と比べると高額になりやすいため注意が必要です。

 

RDS を停止しても 7日後に勝手に起動する

RDS を停止しても 7日後に勝手に起動すると記載しましたが、何か不具合があるわけではありません(笑)

私も昔、検証やテストで使った RDS を削除せずに停止していたところ、後ほど RDS が起動しているのを見てビックリしたことがあります(笑)

この業界では有名なトラップですね。

 

ただし、AWS 側の言い分(?)は以下となっています。

https://aws.amazon.com/jp/premiumsupport/knowledge-center/rds-stop-seven-days/

 

 

この説明を読んで「だったら RDS インスタンスを起動する際に時間をかけてメンテナンスをしてから起動すればいいじゃん。それで RDS の起動に30分くらいかかっても気にしないよ。それよりも勝手に RDS が起動してコストが掛かる方が嫌なんだよ!」と思いました。

 

この7日間問題に対応するには Lambda 関数を作成してスケジューリングして定期的に RDS を起動停止をすればいいようです。

 

 

 

SES

SES(Simple Email Service)について記載します。

 

SES で SMTP 認証を利用する場合は IAM ユーザーが作成されアクセスキーが発行されるので注意

SES のダッシュボードで SMTP 認証用のアカウントとパスワードを発行して、そのアカウントとパスワードを利用して SES からメールを配信することが出来ます。

ここで注意点ですが SMTP 認証用のアカウントとパスワードを発行すると同時に IAM ユーザーも作成され、アカウントキーとシークレットアクセスキーも発行されます。

問題となりそうなのが、「IAM ユーザーは作成してはいけない。スイッチロールのみ認める。例外は絶対に認めない」というガチガチのルールで運用されている場合です。それと「アクセスキーとシークレットアクセスキーの発行は絶対に認めない。発行したら自動的に削除する」というルールだったり、多少ゆるく「アクセスキーとシークレットアクセスキーの発行は認めるがその代わり30日ごとに再発行してローテートしなければいけない」などの場合です。

例外なしで厳密に守らなければいけない場合に何が問題になるかというと、自動的に IAM ユーザーを削除されたり、自動的にアクセスキーとシークレットアクセスキーを無効化されると今まで送信できていたメールが突然エラーになります。

その為最初にアクセスキーとシークレットアクセスキーの運用を確認してから SES を採用するのかどうかを決めるのがいいでしょう。

 

 

 

 

ドメインを管理している DNS サーバのレコードを変更できるかどうか?

例えば、tama-chan.com というドメインを所有しているとします。

DNS サーバは「お名前.com」だったとして、インフラメンバーの自分たちで「お名前.com」にログインして DNS レコードを修正・変更できるでしょうか?

もし「できない」、もしくは「申請して別の部署の情シスの人に作業してもらう」という場合は、障害時に苦労するかもしれません。

障害は夜間・土日に発生することが多いです。

その際にすぐに別の部署の情シスのメンバーを捕まえて作業してもらうことが出来るのか?ある程度の企業になると上長の承認などが必要になってきてすぐにはできないと思います。

そこら辺のリスクも計算して要件定義・設計する必要があります。

 

運用が難しそうなら SES を諦めるのがベストプラクティスです。

無理やり SES を使って現場のエンジニアが無駄に辛い思いをする必要はありません。

 

 

Return-Pathを設定したいか?MX レコードが既に別サービスで使われているか?

例えば、既にドメイン「tama-chan.com」で、AWS ではなく他の業者(例:Pochi株式会社)のメールサービスを利用しているとします。

例えば、nslookup コマンドで tama-chan.com の MX レコードを引くと「mail.pochi.com」が返ってくるとします。(Pochi株式会社のメールサーバ mail.pochi.comがメールを処理している)

 

あらたに SES で「tama-chan.com」ドメインを利用して「test01@tama-chan.com」でメールを送信することはできます。

Return-Path の設定を何もしなければデフォルトの Return-Path(xxxx@ap-northeast-1.amazonses.com)になります。(これはこれで仕様なので何も問題はありません)

しかし事情を知らない(ITやメールの仕様、AWSの仕様などを知らない)偉い人が突然割って入ってきて「え?Return-Pathがamazonses.comになるの?それはおかしいでしょ?tama-chan.comでメールを送信するならReturn-Pathもtama-chan.comにしなきゃいけないよね?」と発言することがよくあります。

というか、現場のエンジニアはそこまで計算しておく必要があります。

 

結論から言えば、すでに他の業者で MX レコードを使って「xxx@tama-chan.com」でメールを送信している場合は SES での「xxxx@tama-chan.com」での Return-Path を「tama-chan.com」にすることはできません。

 

「MX レコードを複数にすればできるのでは?」負荷分散や冗長構成にするために複数のレコードを登録することはできますが、異なるベンダーではできません。

 

そこらへんも考慮に入れて要件定義や設計をする必要があります。

 

 

 

ECS

ECS(Elastic Container Service)の運用のポイントについて解説します。

 

Fargate からカスタム DNS での名前解決が出来ないので注意

Fargate は非常に便利です。

しかし様々な制約があります。

すべて AWS のベストプラクティスに従っていれば何の問題もないのですが、そんなゼロから理想的な構築をできるような企業はないと思います。

大体がオンプレから DB を移行したり、オンプレのこのバージョンでしか動かないアプリを AWS に移行したりとか、口で理想を言うのは簡単ですがスキルやコストや工数や納期などでどうにもならないことが現実の業務にはあります。

 

例えば Fargate でアプリを構築したとして、DB へのアクセスが必要になる場合、DB が RDS で構築されていれば何の問題もありません。

しかしたまに DB サーバが EC2 インスタンスで Windows SQL Server で構築されていて、フェイルオーバークラスタでクラスタ構成を組んでいて、その為 EC2 インスタンスで AD を構築して DNS サーバを兼任していたりします。

「今時そんな企業はないでしょ」と思いたくなりますが、現実問題、様々な企業でよく見かける構成です。

さすがに NT サーバを使っているとかは見なくなりましたが。

 

この場合、Route53 を使ってなくてカスタム DNS サーバを使っていることになりますが、Fargate からカスタム DNS サーバへ問合せをして名前解決が出来ません。

resolv.conf に AD サーバを指定できません。

 

しかし Fargate のタスクが配置される VPC の DHCP オプションセットで DNS サーバーを指定することでカスタム DNS サーバへ問い合わせることができます。

ただ、VPC 全体の DHCP オプションが変更されることになるので、今まで Route53 で名前解決をしている場合はいろいろ支障が出る可能性があります。

 

Fargate でアプリを構築する場合は、カスタム DNS が使えないという点を忘れないように設計しましょう。

 

 

Fargate から外部のメール配信業者経由でメールを送信する場合は 25 番ポート向けに送信できないので注意

Fargate から外部のメール配信業者経由でメールを送信する場合は 25 番ポート向けに送信できないので注意が必要です。

「今時そんなメール配信業者は存在しないに決まっている」と思いますが、いまだに 25番ポートのみ SMTP を受け付けますというメール配信業者がいます。

どんなに頑張っても Fargate から外部の 25番ポートにメールを配信できないので、メール配信業者を選定する際はご注意ください。

 

 

 

Secured By miniOrange