ことの始まり

clamav-milterの検証のため、すでに構築済みのメールサーバーに対して、clamav-milterを導入し運用していた。

導入してから、2～3日後にメールの送受信が行えなくなり、メールサーバーへのsshもできない状況になってしまった。。。(サーバー負荷だろうなと思っていた)

切り戻しをした

(自分一人しか使っていないけれども)メールの送受信ができないと困ってしまうので、一度切り戻しを行った。

切り戻し作業を行っているうちに、clamd, clamav-milterを動かすと、そこそこメモリを消費するということに気づいた。
もともとメールサーバー自体への負荷は低いだろうということで、 2vCPU / 2GB RAMのインスタンスとしていたのだが、2GBのRAMでは足りずハングアップしていたようだ。

htopで見ると、clamdがかなりのメモリを消費している。

スワップ領域を作成した

CPUへの負荷は低く、インスタンスサイズを変更するほどでもないと考え、スワップを領域を作成することにした。

スワップファイルの作成

sudo dd if=/dev/zero of=/var/swpfile bs=1M count=4096
sudo mkswap /var/swpfile
sudo chmod 600 /var/swpfile
sudo swapon /var/swpfile

/etc/fstabへ以下を追記

/var/swpfile none swap sw 0 0

スワップ追加後

スワップ領域に4GBほど割り当てたため、clamd, clamav-milterを動かしても安定して稼働するようになった。

この記事を書いた理由

AWS Amplify Gen2がリリースされたものの、日本語での解説記事が少なく(探し方が悪い？)、困っている人がもし居たら….と思い記事にすることにした。(特にモバイルアプリケーション向けの記事は少ない…)

そもそも、AWS Amplifyとは

AWS上のさまざまなサービスをラッピングし、Webやモバイルアプリケーションに特化したサービス。

詳しくは→https://aws.amazon.com/jp/amplify/

僕はプッシュ通知を送りたい

僕の中で、少し前までモバイルアプリケーション向けのプッシュ通知をAWSで実現したい場合には、Amplifyがすぐ候補となっていた。

周りを見てもPinpointでの実装は少なく、Amplifyでの実装例が多かった。

いつもの通り、amplify initしようとしたら、Gen2使ってねというメッセージが表示され、「せっかくだから…」という軽い気持ちで足を踏み入れることにした。(違いも何も調べずにね)

Get Startからはじめた

Get Startから始めたものの、プッシュ通知に関するサンプルが見当たらなかった。(もしかしたら今後更新されているかもしれない。)

公式ドキュメント以外も探したが、それらしきものは見当たらず…

Gen1のころを思い出した

Gen1の頃に使っていたライブラリと全く同じであることに気づいた。

Amplify Gen2では、バックエンドの構成がtypescriptによるCDKであるため、そこさえできれば実装できそうだ。

そして完成

backend.addOutput({
  /* 省略 */
  notifications: {
    aws_region: Stack.of(pinpoint).region,
    amazon_pinpoint_app_id: pinpoint.ref,
    channels: ['IN_APP_MESSAGING', 'APNS'],
  }
});

これをamplify/backend.tsに記載することで、プッシュ通知の配信対象となった。

addOutputに追加することで、amplify_outputs.jsonに出力されるためだと思われる。

この後について

• Pinpointプロジェクト上でAPNsのキーなどの情報をセットしているが、自動化できれば自動化したい。
• auth周りも実装してみたい。

不要なElastic IPの解放

Elastic IPはインスタンスに紐づいている・いないかかわらず料金が発生するため、未使用な物があれば削除することでコストを削減できる。

※削除の際は、今後使用する機会がないことを確認の上削除してください。

パブリックIPv4アドレスの使用を減らす

2023年にElastic IP以外の通常のパブリックIPv4アドレスに対しても料金が発生するといったアナウンスがあった。
(参考 : https://aws.amazon.com/jp/blogs/news/new-aws-public-ipv4-address-charge-public-ip-insights/)

NAT GatewayやIPv6アドレスでやりたいことを満たせる場合は、パブリックIPv4アドレスを割り当てしないといったことも検討する必要がありそう。

不要なスナップショットの削除

通常のスナップショットの作成以外にも、AMIを作成した際などにもスナップショットが作れれるため、気づかないうちにスナップショットが増えているというケースがありそう。。

気がついたら不要な物はこまめに削除するのが良さそう。

筆者の場合

不要なElastic IPアドレスの解放を行った。
昨年パブリックIPv4アドレスに対して課金されるといったアナウンスをふと思い出し、色々と確認していくうちに気づいた。(遅すぎるよ…w)

結果…

月の途中であるものの、他の月と比べて2/3程度になりそう。。
もっと早く気づくべきだった…

CDN(キャッシュ)の導入

当ブログの構成変更を行なったといった記事を前回(https://engineer-ryo-blog.com/2024/02/18/blog-update/)書いたが、その際にAmazon CloudFrontを導入した。

Amazon CloudFrontの利用にあたっては、いくつかの注意事項があり、注意事項を理解した上で利用する必要があるが、CDNによる非常に強力なキャッシュの力を手にいれることができる。

主な注意事項は以下の通り

• キャッシュして良いもの、キャッシュすると影響が出るものがある。
  例) WordPressの場合、ログインが必要なページ(wp-adminなど)はキャッシュしてしまうと、未ログインのユーザーも閲覧できる状態になる。(見えてはいけないページが見える。)
  ビヘイビアを作成し、キャッシュポリシーを「CashingDisabled」にした上、オリジンリクエストポリシーを「All Viewer」とすることで、キャッシュさせないようにする。
• キャッシュという性質上、リアルタイムに更新される訳ではないので、要注意。
  すぐに反映したいものがある場合は、キャッシュの削除を手動で行う必要がある。
• 初回のリクエストはキャッシュされていないため、オリジンサーバーへアクセスする。
  キャッシュが効いていない状態のため、少し表示が遅い場合がある。
  ただし、2回目以降は、キャッシュから表示するため高速。
• 若干ではあるが、利用料金がかかる。
• AWS WAFも一緒に導入することをおすすめするが、こちらも利用料金がかかるので予算と要件次第。

nginxの設定変更

gzipで圧縮するよう、nginxの設定ファイルへ追記を行った。

gzip on;
gzip_types text/css application/javascript application/json application/font-woff application/font-tff image/gif image/png image/jpeg application/octet-stream;

スケールアップ

今回は行っていないが、スケールアップ(スペックの向上)も検討する必要がある。

当ブログでは、「t4g.micro」を使用しているが、バズることがなければ必要十分と感じる。
※AWS Graviton プロセッサのインスタンスのため、コスト・パフォーマンスが高い。

DB設定のチューニング

当ブログはWordpressのため、テーブル・クエリレベルのチューニングは難しいが、接続先を127.0.0.1からlocalhostへ変更した。

これにより、TCP/IPでの接続ではなく、UNIXドメインソケットでの接続になっているはず…

DBキャッシュ

当ブログでは実施していないが、インメモリDBをキャッシュとしてAP・DB間に配置することで、パフォーマンスの向上が見込まれる。

抱えていた課題

• Amazon Linux 2を使用していて、Amazon Linux 2023への移行が必要となっていた。
• EC2のインスタンスサイズがt4g.micro(2vCPU/1GiB RAM)のため、CDN等でオリジンへのアクセス負荷を減らしたい。

変更前の構成

Amazon Route 53でホストゾーンの管理を行い、EC2でコンテンツ配信(WordPress )という構成だった。

とてもシンプルな構成だった反面、CDNやWAFを導入してみたいという気持ちに駆られた。

変更後の構成

Amazon Linux 2からAmazon Linux 2023へのリプレース、Amazon CloudFront + AWS WAFの導入を行った。

変更後の構成は以下のイメージ。

躓きポイントの紹介

SSL終端問題

SSL終端をCloudFrontにするか、オリジンにするかで悩んだが、結局オリジンをSSL終端とした。

セキュリティグループにて、CloudFront以外からのアクセスはブロックしているが、気持ち的にオリジンが終端であった方がいいと判断した。

キャッシュ対象とCORS問題

WordPressの特定パス(wp-admin)などはキャッシュさせないようにbehaviorで設定している。

また、.cssや.jsが一部httpでhtmlに出力されており、こちらもbehaviorにてCORSの設定を行っている。

まとめ

CloudFrontとWAFの導入によって、レスポンスも良くセキュアに保つことができる構成となった。

また、当初の問題点であったAmazon Linux 2 → Amazon Linux 2023へのリプレースもでき、満足している。

今後もこまめにアップデートしていきながら、記事にまとめていきたい。

参加前の印象

人見知りの自分にとってLT会はハードルが高く、これまで参加を見送っていました。。(登壇者ではないのに…)

偶然こちらのイベントを見つけ、思い切って参加してみることに！

会場へ到着

会場へ到着すると、JAWS-UGいわての運営の方が温かく迎えてくださり、すこしほっとした気持ちで受付を行いました。

ノベルティの配布などもあり、私はJAWSステッカーをいただきました！(いただいたステッカーは帰宅後、PCに貼りましたw)

感想

• アウトプットは大事。LT会などの勉強会から吸収した知識を何らかのアウトプットにしたい。
• 登壇されているエンジニアの皆さんはすごい！(いつかは登壇してみたい！)
• バックエンドの監視のみではなく、フロントエンドの監視も重要。(便利なものがたくさんある。)
• マネージドサービスに頼ろう！
• 無い物は作ろう！

まとめ

すごくざっくりでしたが、LT会に初参加した記録として、ブログに残します。

いつかはLT会に登壇したいです…w