【基本設計編part1】開発未経験がクラウドを企業に導入するプロジェクトごっこをしてみた~その3~

はじめに

２２年度文系学部卒のたいきです。この記事では、システムの開発経験もないのに、見よう見まねで「プロジェクトごっこ」をしていきます。
・保有資格 : 応用情報技術者・AWS-SAP
・プログラミング言語:軽くPython

本記事について

　前回記事で定めた要件定義をもとにして、今回は本プロジェクトごっこの基本設計をしていきたいと思います。下書きをした際に思った以上に、長くなってしまったので、「システムの基本設計」と「クラウド環境構築の基本設計」の二つに分割していきます。
前回記事【明日から社会人】開発未経験がクラウドを企業に導入するプロジェクトごっこをしてみた~その2~【要件定義編】
本企画の最初の記事から読んでいただける方は開発未経験がクラウドを企業に導入するプロジェクトごっこをしてみた~その１~
本記事は、下記のサイトを参考にして基本設計を行わせていただきました。

https://pm-rasinban.com/rd-write
仕様書・設計書テンプレート | 基本設計書・詳細設計書サンプル<

システムの基本設計書

システム化業務フロー

前回の要件定義の内容をより具体的に、少し技術よりに設計してみました

システム機能説明

システム化業務フローの各プロセスを説明したものです。

クラウド構成図

本プロジェクトのクラウド構成図を完璧に自作してみました。多分、これは自分の首をしめることになりそうです。笑　AWS-SAPにて、アーキテクチャの仕方は学びましたが、開発の仕方は全くの無知です。加えて、コードもほとんど書けません。これからどうなるのか、恐ろしいと共にどこまで自力でできるかワクワクしています。非常にチャレンジングです。

簡単にこのアーキテクチャの概要を説明します。
1.ユーザーは、CloudFrontを前段にし、Amplifyでホストされているページにアクセスします。
2.Cognitoで認証
3.S3への写真のアップロードを引き金にイベントを発行しLambda起動
4.アプリケーションでの画像分析
5.推論結果(きのこの山とたけのこの里の各数量)をLambda経由でDynamoDB
6.DynamoDBは24時間ごとにAthenaでデータ型の整形をしS3へ送信するバッチ処理
7.送信後DynamoDBのデータは消去
8.LambdaにてS3のデータを集計し集計結果をcsvに保存(今までのきのこの山とたけのこの里の総計)および、集計結果の更新

アーキテクチャを作成してみて思ったこと

このアーキテクチャでは、s3にて日毎に別のcsvファイルを保持して、バッチ処理時にそのファイルの内容を一つのcsvファイルに保存および集計を想定しています。しかし、個人的にもうちょっと賢いやり方があるのでは、、、？と考えています。もしかしたら、リアルタイムでランキングを更新したりするアーキテクチャを参考にできるかもしれませんので、開発時に変更があるかもしれません。

各AWSリソースの概要説明

セキュリティ自動化アーキテクチャ

これも、またまた難しそうなものを見つけてしまいました。このアーキテクチャは、AWS公式さんが設計の開発方法を公開しているのでそちらを参考にしていきます。

https://aws.amazon.com/jp/solutions/implementations/aws-waf-security-automations/
AWS WAFセキュリティオートメーション

上記のAWSが推奨するAWS WAFを用いた自動化アーキテクチャを採用します。このアーキテクチャは４つの方法によりD-Iの６つの脅威から防ぐことができます。
1.WAFへのアクセスログに基づくWAFルールの更新によるアクセス制御
2.アプリケーションへのアクセスログに基づくアクセス制御
3.ハニーポットの設置による攻撃者の特定及びアクセス制御
4.サードパーティー企業所有のIP元評価リストの活用によるアクセス制御

おわりに

基本設計において、顧客側・技術者側両方にシステムの設計意図ができるだけ伝わるように頑張ってみました。技術の説明を、深すぎず浅すぎずといった感じです。今後ですが、この基本設計をもとに開発していきます。詳細設計に関しては今回作成しません。理由としましては、私自身がアーキテクチャの知識しかなく開発の知識が全くないからです。現段階では、利用するコードなどの想像が全くできていません。開発は、その場その場で壁にぶつかりながら試行錯誤をしながら開発していきます。Googleさんを頼りに。笑

4/6編集

前回のアーキテクチャでは、きのこの山とたけのこの里の総計更新は日次の更新でした。しかし、開発容易性およびユーザービリティの観点から、ユーザーが集計APIを発行すると同時に集計し、結果を得るという感じにしようかなと思います。日ごとの集計結果は、csvとしてS3に保存します。
どうなんですかね、API発行ごとに集計ってめちゃくちゃリソース消費するっていうか現実的ではないような気がしてきましたね、、、。５分毎に結果が更新とかにしたいんですけど、どうしましょう。５分毎に、Dynamoがクエリして総計をなんらかのストレージに保存してAPI GETさせるほうがいいような気がしてきました。したのアーキテクチャに関しては急遽変わるかもしれません。