# 不動産仲介会社や管理会社向けに内覧の予約と履歴を管理するシステム
アプリで予約から解錠、履歴確認までを一元管理可能。
## チーム情報
- 顧客（システムを運営する企業の社員）：10名
- リーダー：1名
- 開発メンバー：2名
## 開発メンバーとして以下の業務を実施
開発のメンバーとして以下の作業に従事した。
- お客様からの要件ヒアリング、要件定義
- お客様との定例(Zoomを利用し開発進捗報告など)
- 設計(要件から機能設計書の作成、詳細設計)
- 工程管理、工数見積
- インフラ設計、構築(AWS)
- 開発
- テスト
- 保守運用(障害対応、調査など)
- リリース作業
### EC2からFargateへの移行作業
#### 使用した技術
- ECS
- EC2
- Fargate
- ALB
- GithubActions
- Ruby on Rails
- nginx
Fargateの導入に関しては、自分自身が調査をし、技術検証を実施後にお客様に対して提案をした
#### プロジェクト概要
システムを導入される企業のセキュリティ基準に対応するために、「サーバーOSに対してセキュリティパッチを適用してほしい」という要望があった。
セキュリティパッチを当てる運用を検討してみたが、インフラ専門がいない中で自力でセキュリティパッチの影響範囲の調査や更新作業が発生するため運用コストが高いと感じた。
元々ECS on EC2で運用していたので技術ブログや記事などでFargate移行についてイメージしていたことと、コンテナでの運用は数年経過していて慣れていたことから移行をお客様に提案した。
管理コストが削減できる運用面の話と、コスト面でも既存のEC2のリソースを現状利用しきれていないことからほぼ同じ金額になることを説明した。
#### 取り組んだ課題
AWSで移行に関する資料を公開されていたので参考にして、コスト見積もりやタスクを明確化させていった。
具体的には新規でECSサービスとロードバランサーを作成し、ロードバランサーの加重ターゲットグループを利用することでターゲットグループへのトラフィックを設定できるので、徐々にFargateのみにトラフィックがいくようにして移行していった。
タスク定義の修正、コンテナのリソース調整、スケーリングポリシーの調整を実施してリリースをした。
1ヶ月ほどEC2とFargateの2つで運用していたが、問題が特に起きなかったのでEC2を削除した。
#### 取り組みの成果
注意した点としてはDNSのトラフィック振り分けではなくロードバランサーの振り分けにした点で、参考にしたAWSの移行資料ではDNSを利用していたが、ユーザー側のキャッシュの問題か何かでEC2にリクエストが残ってしまうとのことだった。その資料でも提案されていたロードバランサーによる振り分けを採用することでその問題は起きなかった。
結果的にEC2とFargateのこすともほぼ同等か安くなる結果になった。
## バッチ処理環境の構築
#### プロジェクト概要
CSVのデータをDBにインポートするバッチ処理をしたいという要望があった。
#### 取り組んだ課題
- Fargate、Lambda、AWS Batchを起動時間や大量のデータの処理において比較をした。
- 処理時間15分は越えないのでLambdaでも問題ないが、既存で運用しているインフラ資産を流用する形でFagateにした。
- 具体的にはロググループ作成、エラー判定用のメトリクス作成、EventBridgeにAlerm作成、SNSでメーリングリスト作成、S3にバケット作成した。
- S3にCSV形式が保存→ECSタスク起動→失敗→ログが出力される→メトリクスがしきい値を超える→Alermが発火する→SNSに通知がいくという処理の流れを構築した。
#### 取り組みの成果
- バッチ処理の実行が可能になった。
- 別のバッチ処理が必要になった場合でも同じ仕組みで実行が可能になった。
## CI環境の再構築
#### プロジェクト概要
プロジェクト開始時からWerckerを利用してデプロイをしていただ、Oracle社の方針によりサービス終了したため、CI環境を再構築する必要が出た。
#### 取り組んだ課題
- Pull Request のレビューの Approve や Change Requested イベントがトリガーになることやデプロイ回数からして無料枠で利用できることからGithubActionsに決めた。他の比較対象はCircleCIがあった。
- ECRのイメージスキャンが利用できるということで、サーバーイメージのセキュリティチェックが可能になるということで、サーバーイメージ管理をDockerHubからECRへ変更した。
#### 取り組みの成果
GithubActionsでのデプロイが可能になった。
## ruby, railsのupgrade
#### プロジェクト概要
5年ほど運用されていたアプリケーションでruby, railsのupgradeが一度も実施されていない状況だった。
#### 取り組んだ課題
- rspecのテストカバレッジ率を67%だったものから75%まで単体テストを追加した。
- 各種gemのアップグレードを実施した。
- rspecやrubocopなのどチェックを利用しながら既存コードの修正をした。
- 開発環境で実際に動かし、動作確認用のチェックシートを作成し、クライアントとダブルチェックを実施した。
- エンジニア側と実際に利用するクライアントで問題ないことが確認できた後に本番環境へリリースを実施した。
#### 取り組みの成果
ruby2.3→ruby2.7.8、rails4.2→rails5.2へのupgradeが完了した。
## 同アプリのIOS, Android版改修、リリース申請作業
言語はSwift, Java
サーバーから受け取るパラメーターの修正、文言修正などの軽微な修正とリリース申請作業を実施した。