はじめに
2024/3/3開催のJAWS-UGイベントにて、
自分の業務に関わりの深いLTを備忘のため簡潔にまとめました。
※LTの内容と自分のコメントが混ざっているのでLTだけの要約ではないです。
こういったイベントで得た情報は翌日以降に忘れがちなので、
こういった機会で知れた/興味を持てた内容をピックアップしてまとめようと思います。
E-1CIer・Sier集まれクライアントワークな私たちとAWSの良い関係
概要
AWSを利用した受託開発を経験された3名のCIer・SIerによるパネルディスカッション
まとめ
- 顧客への事業影響を第一に考えるのが本当に大切
- 新サービス使おう/コンテナにしようはSI側の希望なだけ
- そのアップデートは顧客にどのような影響があるのかを考える
- AWSアップデートキャッチアップ勉強会にはメリット多数
- 他のPJ定例の際に、その問題は最近のアップデートで解消されたと気付ける
- W-AレビューのタイミングはPJ都合だが早ければ早いほどいい
- ★コスト最適化のレビューは要件が固まると改善困難
セッションメモ
バージョンアップの提案のコツを教えて
AWSは良くも悪くもOS/機能GAなど頻繁にバージョンアップが行われる。
また、クリティカルな問題であるランタイムサポート切れEOLなどの説明はどうするのか？
回答
- 前提としてバージョンアップには色々な種類がある。大きく分けるとホラーストーリーが明確な「必須対応」と不明瞭な「任意対応」
- OSのEOLなど「必須対応」の場合は、やらなきゃいけないからやるしかない。
- 新機能のGAなど「任意対応」の場合は、お客さんの事業メリットを踏まえて提案を行う必要がある。
- 〇〇なオペレーションに対して効果がある。顧客内社内リングに通しやすくする。
- 新規構築時に対応しなかった機能が使えるようになったからやろう
- 検知の仕方の説明になるが「AWSHealthDashboard」通知、「各サービス/OS」アップデート情報を確認して、お客さんのメリットを確認する。
- やる場合はリスクについて必ず検討すること
- 既存システムへの導入も費用がかかるから、その説明は難易度が高い
新機能がGAされたときの提案どうする？
AWSで大変な新技術のキャッチアップについて
回答
- 月次の運用情報のご報告があるからそこで出してもらっている。
常に顧客の事業メリットを踏まえて提案している - アップデート情報のキャッチアップとなるが、本当に大変。
AWSブログで新しいアップデートがあれば通知してもらい、アップデートの報告会が効果的。 - GA/アップデートが多すぎて普通に生活してたら負えない。
週に1回アップデートをサラッと追う会を実施している。
追う会を実施すると、別でPJ課題を共有するミーティングがありそこで他の担当者が気づくことがある。 - アップデートされたサービスを追うのはつらい。
AWSパートナー企業であればSAAと協力して進めても〇
クライアントに響いた口説き文句
説明する際にクリティカルなメッセージを聞きたい
回答
- スタンスはビジネスパートナー御用聞きやいわれたことではなく、
顧客の事業の成長に必要なことをシステム化
顧客との協創意識を常に持つ。お客様の文化を作ることを推している - コンテナやサーバレスはSE都合お客さんとしては早ければEC2でいい。
そういったところもお客さん背景を踏まえて説明するといい。
技術的負債の解消ってできている？Well-Architectedじゃないけどどう変える
日々アップデートされるAWSは技術負債が多くなりがち。放置しているの？
回答
- 当時はその作り方でいいけど現在W-Aに沿った設計ではない。
W-Aに沿っていない問題は顧客が解決したい課題では絶対にない。今後どうする？ - 新規に構築している顧客には品質保証を目的としてやっている
マルチAZで金かかるならシングルでいいといわれるが、
お客さんの意思決定ならば良い。スコア結果を元に状況の可視化が本当に大切。 - PJ推進に当たってWAは大変。要件定義とかでWAやるのは無理。
提案段階でWAを全部するのは大変だから簡易的にチェックを行べき。
WA推奨の設計/リリース前は無理だから段階的にやっていく - WAレビューにてコスト最適化の柱は、企画段階で適用しないとだめ。
出来上がった後にコストを検討するため、後手に回ることが多い。
ハイリスクなシステムでもWAについては現状システムに対するリスクでも可視化することが大切。まずは可視化してお客さんが認識していればそれでよしとする。 - 直近の技術負債が生まれれる更新として、ZEROETLがある。
ZEROETLを適用すれば解消できる問題がいっぱいある。
※Aurora-Redshiftの連携システムがあるとやばい。
入れ替えるにしてもコストをどうするのかが重要な観点になる。
その他やってよかったこと
- Sierは顧客志向でAWS社と付き合っていくと良い
- 一緒にAWS営業と顧客のミーティングに行くとかもアリ
- もしかしたら、顧客側の信頼感も上がり別案件に繋がるかも？
- 一緒にAWS営業と顧客のミーティングに行くとかもアリ
A-3 サービスクォータちゃんと監視していますか？
AWSの公式ソリューション「AWS でのクォータモニタ (Quota Monitor for AWS)」を使ってサービスクォータを監視する方法を紹介
- まとめ
- クォータ枯渇を防ぐには監視が必要
- 監視に便利なのが「AWSでのクォータモニタ」
- シングルアカウントであれば最小3ステップで導入可能
- クォータモニタ範囲外の重要クォータは「CloudWatch」「ServiceQuotasの簡易アラーム」利用
セッションメモ
-
サービスクォータ枯渇の問題
- 枯渇すると新規リソースの作成がNGとなる
-
枯渇したときに申請すればよいのでは？
- 増加リクエスト＝即時ではない。タイムラグがある。
-
クォータ枯渇への対応方法
- クォータ枯渇を防ぐには監視が必要！
- クォータ状況を監視することはBestPracticeであり、WAにも記載があり。
- クォータ枯渇を防ぐには監視が必要！
-
クォータ監視サービス「クォータモニタ」
- 閾値を超えたら、Slackやメールで通知
- CloudForamtionでテンプレートがあり導入が容易
- 料金：最低料金12.25ドル(アカウント量などで変化)
-
シングルアカウントには3ステップで導入できるよ
- hub-no-ouスタックデプロイ
- Systemmanagerパラメータ更新
- sq-spokeスタックを起動
- 閾値のチューニングもできる、
3.b ta-spokeスタック
- ビジネスサポートプラン契約しているならこれも候補。
- Spokeのスタックは併用がおすすめ
- Organizationの利用も合わせると良い
-
範囲外の重要クォータはCloudWatchで補完する
- Lambdaの同時実行数とかはクォータモニタで監視ができない
-
ServiceQuotasでつくれる簡易アラームも検討
- Lambdaの同時実行数も検知可能
E-4 全方位でのAWSコスト管理：最適化、削除、そしてガバナンス
請求情報やAWS Cost Explorerが利用できない場合でも、
コスト削減の余地を捉える方法について解説
補足リンク：https://www.qes.co.jp/media/aws/a363
- まとめ
- 請求関連情報が見れなくてもCloudWatchメトリクスからRI/SPの購入検討は可能。
- AWS共通リソースやクレジットもしっかりコスト管理しよう
- RI/SP以外でも複数の観点からコスト削減は可能
セッションメモ
- 請求情報やAWS CostExplorerが利用できない環境下でのRI/SP購入の判定方法
- RI/SPを購入する必要があるかもしれないが、請求関連の参照権限がない人向け
- 共通リソースから考えるコスト管理
- AWS全体のコスト管理を行う方向け
- 開発エンジニア目線で考えるコスト管理
- AWSで設計/開発を行うエンジニア向け
請求情報やAWS CostExplorerが利用できない環境下でのRI/SP購入の判定方法
- RI/SP購入を検討しているが、対象リソースの選定が困難
- LambdaやCLIを使用してCloudWatchメトリクスから稼働状況を確認し、判断基準とする
RI/SPおさらい
- RI購入可能なサービスは以下の通り
- EC2
- RDS
- ElastiCache
- Openserch
- Redshift
- SP
- EC2
- Lambda
- Fargate
- SageMaker
- 以下状況のリソースではRI/SPの活用を検討しよう
- 長時間稼働されているインスタンス
- 長期的コミットメントが予測されている
- 仕様にも依存するので、長期コミットメントより長時間稼働インスタンスが該当しやすい
- RIの購入判断基準(例:EC2)
- Lambdaで各インスタンスごとに以下情報を取得/計算することで、インスタンスが起動している時間の割合を把握し、RI購入の判断基準になる
- 直近24hのCPU使用率のメトリクスを1hごとに取得
- CPU使用率が1%以上の時間帯の数を計測し割る24
※日々の停止/起動の運用状況で情報取得期間は変更する - 本情報を参考にAWS Pricing Calculatorで削減可否をシミュレーション
- Lambdaで各インスタンスごとに以下情報を取得/計算することで、インスタンスが起動している時間の割合を把握し、RI購入の判断基準になる
- SPの購入判断基準(例:Fargate)
- Lambdaで各クラスター単位で予約されている以下情報
- 予約されているメモリ
- 予約されているvCPU数
- SP購入においては稼働率は影響ないため、1時間ごとの使用率を確認
- Lambdaで各クラスター単位で予約されている以下情報
AWS環境を共通利用する場合のコスト注意点
- 一般的には「Organizations配下のマルチアカウント」「同アカウント複数システム稼働」など
」コスト配分タグによるコスト配分を実施しているが以下問題がある
- AWS共通利用リソース費用の按分
- DirectConncet、TransitGatewayなどNW系要素に関する費用
- セキュリティガバナンスに関する費用
- AWSサポート費用
- 付与クレジットの適切な計算
AWS共通利用リソース費用の按分
- AWSの共通リソースのため、明確なコスト分配が困難
- コスト管理の第一歩として、各部門のAWS利用料に応じて割合を算出し、
按分することが推奨
- コスト管理の第一歩として、各部門のAWS利用料に応じて割合を算出し、
開発エンジニア目線でのコスト削減
- リージョン変更
- リージョン変更に伴い、確認観点は多数あり
- 仕様プロセッサを変更
- 仕様プロセッサ変更に伴い、確認観点は多数あり
- スポットインスタンスの利用
- ログ出力形式の検討
-
どんなログでもCloudWatchLogsに出力していないだろうか
- ログ監視を行うログだけをCloudWatchLogsに送信
- それ以外はS3に直接保管するようにしておく
- CloudWatchLogsも一定期間でS3に出力するようにする
※S3を利用する場合でもintelligentTieringを利用するなどコスト削減を狙う
- EC2の場合
- CloudWatchAgentでフィルタ設定をして必要なログのみCloudWatchLogsに送信
- ECS Fargateの場合
- awslogsドライバではなく、FireLensを利用することでログの投げ分けをすることができる。
-
B-5 AWSSecurityhubとAWSOrganizationで最強セキュリティ設定
- AWS ConfigとOrganizationでセキュリティ強化
- 目指すべきゴール
- 設定さえすれば完全に自走
- セキュアなアカウントを作成する。
- Organizations
- SCPを使用して、組織全部の管理
- Configでセキュリティグループの解放とかを評価し、自動的に修正させる
- ★RABに使う
- Configルールほしい
- Organizationsuでアカウント全体/Configでアカウント個別に確認
A-11 AWSセンセーション私とみんなが作ったAWSセキュリティ
- まとめ
- InsepectorがEC2以外(ECR,Lambda)に適用できるの知らなかった。。
- この人の知識量すごい