ID:66647さん

### プロジェクト概要 #### 目的、背景 - オンプレ既存システムの老朽化 - AWSの各種マネージドサービス利用による運用管理コストの低減 #### 規模感、チーム構成、担当した役割 - 規模感 : 2～3ヶ月 - チーム構成 : AWSチーム担当者は自分 1名、レビュア 1名 - 担当した役割 : AWSアーキテクチャ検討、見積もり、設計、構築、テスト #### 使用技術や開発環境等 - CloudFront > ALB > EC2 Apache (AutoScaling) > EFSというアーキテクチャ - 証明書管理は ACMを利用 - EC2への接続のために SSH over Session Managerを利用 - バックアップのために AWS Backup, メトリクス監視のために CloudWatchを利用 - これらの AWSリソースの開発環境構築、本番環境構築を IaC (terraform, userdata) で実施 ### 取り組んだ課題 - 課題１ - CloudFrontや AutoScalingなどいくつかの AWSサービスに対する実績が部内になかった - プロジェクト全体を通して対応できるよう、公式ドキュメントやハンズオンなどで予習しながらプロジェクトを進めた - 課題２ - 開発環境で確認できたテスト結果を本番環境においても担保したかったため、可能な限り IaC (terraform, userdata) を利用して環境構築を行うようにしたかった - terraformリソース数は 175個, userdata数は 5個という規模のシステムに対して IaCを適用したのは AWS主管部署にて初の試みだったが、スケジュールに遅延なく独力で対応することができた - 課題３ - ドメイン管理は Route 53には移行しないお客様要件のため Route 53の Aliasレコードが使えず、Zone Apexの名前解決方法を検討する必要があった - Zone Apexの名前解決は Global Accelerator向けの Aレコードで行い、Global Acceleratorのターゲットに ALBを指定、ALBの httpリダイレクト機能を利用することで解決した - 課題４ - 開発期間中はセキュリティのため外部の不特定多数が Webへアクセスできないように制御したり、簡易な httpリダイレクトを設定したりしたかった - CloudFront Functionsのスクリプトにてベーシック認証やリダイレクトを実装できるか検証し、解決した

### プロジェクト概要 #### 目的、背景 - 当社の AWSリセールサービスをご契約いただいているお客様に付加価値を提供するため (契約解除防止のため) #### 規模感、チーム構成、担当した役割 - 規模感 : 2～3ヶ月 - チーム構成 : AWSチーム担当者は自分 1名、レビュア 1名 - 担当した役割 : AWSアーキテクチャ検討、見積もり、設計、構築、テスト #### 使用技術や開発環境等 - EventBridge (cron) > Lambda > DynamoDB, S3 > Lambda > SaaS (Zendesk) というアーキテクチャ - 処理の流れ - 定期的に EventBridgeから Lambdaを起動し、セキュリティチェックを実施 - 当社の AWSリセールサービスをご契約いただいているお客様の全てのリソース情報を参照し (Assume Role)、チェック結果を DynamoDBへ書き込み - チェック結果を DynamoDBから読み込み、Excelファイルへ出力、S3へアップロード - S3トリガーにて Lambdaを起動し、Zendesk APIを実行してチケットを発行、お客様は Excel添付ファイルを受信 - Lambdaは pythonと golangで実装。golangは Excelライブラリが必要な Lambdaにて使用し、他の処理は pythonにて実装 ### 取り組んだ課題 - 課題１ - DynamoDBの書き込みスループット超過エラー - 原因はパーティションへの負荷だったため、パーティションキー値が分散するよう sleep処理を組み込んだことでエラーが発生しなくなった。また、念のためエラー発生時のリトライ処理も実装した - 課題２ - DynamoDBの読み込みスループット超過エラー - 総合テストにて連続運転テストを実施していたところ、読み込み対象リソースが存在するにも関わらず Excelファイル (チェック結果ファイル) にリソース情報が出力されなくなってしまった。そしてエラーは特に発生していなかった - 原因はチェック結果が蓄積されている DynamoDBのデータ量が大きくなり、読み込み APIのクォータを超過したため。読み込み APIを Scanから Queryへ変更し、抽出条件を指定することでクォータに抵触しなくなった。また、念のためエラー発生時のリトライ処理も実装した

### プロジェクト概要 #### 目的、背景 - 当社の AWSリセールサービスをご契約いただいているお客様に付加価値を提供するため (契約解除防止のため) #### 規模感、チーム構成、担当した役割 - 規模感 : 2～3ヶ月 - チーム構成 : AWSチーム担当者は自分 1名、レビュア 1名 - 担当した役割 : AWSアーキテクチャ検討、見積もり、設計、構築、テスト #### 使用技術や開発環境等 - EventBridge (cron) > Lambda > DynamoDB > SaaS (Zendesk) というアーキテクチャ - 処理の流れ - 15分置きに EventBridgeから Lambdaを起動し、AWSが公開しているサービスヘルスダッシュボードの RSSを取得 - 前回処理にて DynamoDBへ控えておいた RSS情報と照合し、不一致の場合は RSSが更新されたと判断して顧客通知用のチケットを生成 - Lambdaは nodejsで実装 ### 取り組んだ課題 - 課題１ - RSSの日本語化対応 - RSSは基本的に英文でありお客様にとって視認性が良くないと想定されることから、AWS Translate APIを利用して英語から日本語へ自動変換した