「ついで」に管理してたインフラに対する気付きを殴り書き

経緯

新卒から4.5年間, ソシャゲ運用のプロジェクトに携わっていました。
自分が担当した全てのプロジェクトでインフラ専門の方がいなかったので, 3年目くらいからアプリ運用の「ついで」に AWS 管理も行っていました。
当時はコストが大きくなりすぎずとりあえず動けばいいみたいな管理でした。

この記事はそんなとりあえず動いているインフラに少し手を加えるだけで改善しそうなことを、思いついたときに書き留めていきます
別業界のインフラエンジニアに転職したので気づいたことを備忘として書いてって、今後役に立てばいいなって思ってます。
思いつきで試してないので実際にやったら実用的じゃないことのほうが多いかもしれません。
もちろん間違ってることもあると思うんで信じすぎないようにお願いします。

qiita の使い方もよくわからんけどな

目次

1. EC2 インスタンスタイプは定期的に見直す
2. 機能別メンテナンスは ALB でできるかも
3. AWS Timestream 使ってみたい
4. このアーキテクチャ構成図すごくない？

EC2 インスタンスタイプは定期的に見直す

AWS EC2 のインスタンスタイプってどんどん新しいのが出てて, 基本的に新しいほうがコスパがいいみたいです。
なので特に何もなくても 1回/年 くらいでインスタンスタイプ見直したほうがいいんじゃないかなって思いました。
何も考えてなかった自分は汎用の m5 などを使用していたのですが少し考えるだけでかなりコスパの改善ができそうです。
具体的には R5, M6g, R6g を使用したほうがいい気がしましたね。

• CloudWatch 見て CPU よりメモリのほうがネックになっているなら r5 の方が良さそう
• arm に対応してるならたぶん Graviton 使ったほうがいい

AWS では今後も Graviton の開発が進むだろうし, そもそも設計の段階で arm に対応するだけでかなりコスパがよくなりそうです。
EC2 って書きましたが RDS Aurora でも利用できるのでそちらも検討する価値があります。
2022/11/09

機能別メンテナンスは ALB でできるかも

自分が携わってたプロジェクトでは機能別メンテナンスの実装ってなくて、定期的に全体メンテナンス入れてデプロイしてました。
部分的に不具合があったときでも緊急のものは全体メンテナンスで対応していた記憶があります。
やるとしたら DB とかで機能ごとにフラグつけて API リクエストごとにチェックするんだろうなって思ってた記憶があります。
でもこれ ALB のリスナールールにパス指定で /api/contents/* を S3 に飛ばすってルールを優先度を 1 で追加すれば解決する気がしました。
api リクエスト挟まない画面遷移なんかは弾けないですが, それはサーバ側からパブリッシュする実装がないと同じなのでお手軽機能別メンテナンスとしてはありかなと思いました。
2022/11/09

AWS Timestream 使ってみたい

AWS Timestream が 2022/7 くらいに東京リージョンで使用できるようになったらしいです。
使うことで何がどれくらい改善されるかは調べてないのでまったくわかりません。
ただ昔全部 RDS に保存してて過去のデータ集計して分析するの苦労してたり, Kinesis から吸い上げたデータを S3 に入れて Athena で整形して BI ツールに落とすのが重い記憶があります。
整形する必要があるのは変わらない気がしますが, コスパの面ではかなり改善できるような気がしています。
2022/11/09

このアーキテクチャ構成図すごくない？

自分の経験が足りないだけなのかもしれませんが, この構成図を見たときはびっくりしました。
アーキテクチャ構成図をたくさん見てきたわけではないので, インフラ業界の中にはもっとすごい(?)構成図があるのかもしれませんが, マジか！？って思いました。
インフラって本気を出すとこんなに多くのサービス/コンポーネント使って構築するんですね。
動画内で「ネットにアクセスしていることを感じさせない」ことを目指したといっていました。
言うは易く行うは難しでしょ、って思ってましたが自分が向き合ってなかっただけなんだと痛感させられましたね。

この構成の工夫されている部分やどういう点に優れていて何を犠牲にしてるかは全く理解できていません。
今後数年間は, この構成図を理解できるようになることを目指していこうと思います。
いつになるんでしょうね笑
2022/11/10

なぜ Rails の前段に Nginx を置くのか

ゲーム以外のサービスに関わったときにwebサーバとappサーバを別で立ててるのを見て、apiサーバをMVCにしてればwebサーバいらないじゃんと思ったので軽く調べてみました。
まとめる時間と気力がないので先人に頼ります。
ゲームでは静的コンテンツの配布が多くないと思うので、記事を読んだうえで不要だと判断するのもいいと思います。
2023/04/13
https://qiita.com/emacs_hhkb/items/818f54b75a14832d9d16

↑について chatgpt に聞いてみた

MVCモデルの前段にあるWebサーバの役割は、主に以下のようなものです。

1. クライアントからのリクエストの受付と処理: Webサーバは、インターネット上のクライアント（通常はWebブラウザ）からのHTTPリクエストを受け付け、適切に処理します。その後、リクエストに応じて、静的ファイル（HTML、CSS、JavaScript、画像など）の提供や、アプリケーションサーバ（MVCモデルを実行するサーバ）へのリクエストの転送を行います。
2. 負荷分散: 大規模なWebアプリケーションでは、複数のアプリケーションサーバを利用して、リクエストの処理負荷を分散させることが一般的です。Webサーバは、負荷分散の役割も果たし、入ってきたリクエストを複数のアプリケーションサーバに適切に振り分けます。
3. セキュリティ: Webサーバは、インターネット上からの不正なアクセスや攻撃に対して、アプリケーションサーバを守る役割を担います。例えば、ファイアウォール機能や、特定のIPアドレスからのアクセス制限、SSL/TLSを利用した通信の暗号化などのセキュリティ機能を提供します。
4. キャッシュ: Webサーバは、静的ファイルのキャッシュを行い、アプリケーションサーバへのアクセス負荷を軽減します。また、一部のWebサーバでは、動的コンテンツのキャッシュも行うことができます。

＞ リクエストはapiサーバで受ける
＞ 負荷分散はalbでやる
＞ セキュリティはwafやsgでやる
＞ 静的コンテンツのキャッシュはcloudfrontでやる
＞ webサーバ必要？

ご説明いただいた状況では、既にAPIサーバ、ALB（Application Load Balancer）、WAF（Web Application Firewall）、セキュリティグループ、およびCloudFrontなどのAWSサービスを利用して、Webサーバの役割を十分にカバーしているようです。

これらのサービスを適切に設定して運用していれば、従来のWebサーバを設置する必要はありません。モダンなクラウド環境では、従来のWebサーバが担っていた役割が、各種のマネージドサービスやコンポーネントに分散されて実現されています。

ただし、状況や要件に応じて、Webサーバの設置が適切な場合もあります。例えば、特定のWebサーバ固有の機能やカスタマイズが必要な場合や、サードパーティ製アプリケーションがWebサーバを必要とする場合などです。しかし、ご説明いただいた状況では、Webサーバを設置する必要はないと考えられます。

2023/04/14

メモ

SNS, SQS とか NoSQL をまともに触ってないのでそのうち調べて使えるようになりたい
マイクロサービスアーキテクチャっていう文化も馴染みが無いので学びたい
冪等性の担保とか疎結合化はパフォーマンスへの影響が大きそう

最後に

冒頭に記載したように思い付きを殴り書きしているだけなので, 正しくないことが多々あると思います。
それでもこの記事がインフラについて調べるきっかけになって, サービスの質向上につながれば幸いです。
ありがとうございました。

参考

サーバCPUもArmの時代になりました
Amazon Web Services Japan 公式 youtube チャンネル
時系列データを扱う新しい選択肢？！ Amazon Timesteram を試してみた
AWS でのゲームエンジン積極活用手法のご紹介(AWS-30)