# 取り組み内容
未経験であった AWS を利用し、一人でインフラを立ち上げ、工場内のデータを見える化する仕組みを構築しました。現在、私は製造業で製品の検査工程を担当し、設備設計（ 回路設計 ）および検査ソフト設計（ 組み込みのC++ ）を実施しています。製造業では、ソフトウェアに関する知見を持ったエンジニアが少なく、システム化が行われないために、さまざまな業務が手作業で行われています。こういった現状を解消するために、検査業務とは別に個人で改善業務に取り組んでいます。
検査業務は、設備設計や検査ソフト設計に加えて、生産中に故障した設備の調査や、検査ソフトの不具合調査などを実施します。これらの調査は、csv 形式のダンプされたログを手作業で集計し、データの解析を行っています。不具合により設備が停止すると生産能力が低下し、生産性の悪化に繋がります。最悪の場合は、納入遅延を引き起こす大きな問題となります。そのため、できる限り早期に原因を発見し、対策する事が必要不可欠です。
この課題に対して、新たにシステムの導入を検討しました。簡単に試せる環境が無かったため、使えるサーバを探し、生産で使われていた廃却予定のサーバを入手しました。サーバには、Cent OS をインストールし、様々なシステムの検証を効率よく行うことができるように Docker をセットアップしました。その頃に別の目標として取り組んでいたバージョン管理やナレッジ管理を実現するため、Docker 上に GitLab や Growi の導入を試しました。様々なシステムを調査し試していく中で、Prometheus、Grafana、Elasticsearch の存在を知りました。
検査データの見える化を実現するために、csv 形式のログファイルを加工しデータベースに取り込み、監視できるシステムを検討し始めました。手掛け始めた頃は、 Prometheus、Grafana で実現することを検討していましたが、調査する中で ElasticStack を利用すると、csv 形式のログファイルが容易に加工できる事を知り、ElasticStack に決定しました。
Docker Compose 上に、Filebeat、Logstash、Elastic Search、Kibana、Metricbeat をセットアップしました。csv 形式の検査データは、構造が特殊であることや日付のフォーマットが一般的ではありませんでしたが、Filebeat の Multiline を利用し、Logstash のカスタムフィルタを作成することで解決しました。また、Logstash の pipeline の保守性と再利用性を向上するために、[パイプラインの構造を工夫](https://www.elastic.co/jp/blog/how-to-create-maintainable-and-reusable-logstash-pipelines)しました。Elastic Stack を利用し、検査データの見える化を実現しましたが、サーバのスペックが限界であったため、１製品に限定することとなりました。また、検査業務を実施しながら、サーバの運用を行うことに限界を感じ始めました。
この頃、isucon に参加し AWS の利用を始めました。そして、CloudFormation を利用することで、デプロイの自動化が出来る事などを知り、AWS に興味を持ち始めました。Elastic Stack のクラウドでの運用を検討するため、社内のシステム部署に相談したところ、グループ会社全体で AWS を利用している実績がある事を知り、AWS への移行を検討しました。検査データの見える化は自部署だけでなく、他部署にも恩恵のあるシステムであるため、システム紹介を実施し、導入することでどの程度の効果が得られるか算出していただきました。年間１０００時間程度の業務時間の削減効果があることがわかり、システム部署の協力を得ることができました。
AWS への移行を部方針に入れ、本格的に導入計画を実施しました。社内では、AWS だけでなくパブリッククラウドの利用実績はないため、手探りで導入を始めました。セキュリティ点検表の作成も初めてであったため、サポート窓口への問い合わせや調査を行い作成しました。なんとかアカウントを取得し、３ヶ月で工場内のデータを見える化することができました。システムの構築は、オンプレ環境で課題となったサーバのスペックや運用についての問題を念頭において、サーバのオートスケールが出来て、運用が効率化できる仕組みを検討しました。
技術的な問題に対する取り組みは以下の通りです。
* [CloudFormationで全てのシステムの立ち上げを自動化](https://zenn.dev/s_tomoyuki/articles/0005-aws-iac)しました。また、開発効率を上げるため、CodeCommit、CodeBuild、CodePipeline を利用してデプロイを自動化し、これらのデプロイ環境についてもCloudFormation を利用し自動化しました。
* [信頼性を向上させるための仕組み](https://zenn.dev/s_tomoyuki/articles/0002-aws-multi-az)を取り入れました。マルチ AZ を利用した冗長化に加えて、サーバのスペックの問題を解消するため、ECSを利用しオートスケーリングできるようにしました。
* セキュリティに関しては、[脅威検出結果をチャットツールに通知](https://zenn.dev/s_tomoyuki/articles/0004-aws-guardduty-notification)できるように Lambda を実装したり、cfn_nag_scan、cfn-lint といった静的解析ツールの導入を行いました。
* コストに関しては、[Fargate Spot を利用した最適化](https://zenn.dev/s_tomoyuki/articles/0003-aws-fargate-spot)を行いました。これらの取り組みによって、サーバスペックの問題、運用工数の課題を解消しました。
# プロジェクトを通してスキルアップしたこと
* AWSのサービスを利用し、一人でインフラ、セキュリティの構築ができるようになった。
* マルチAZ環境での可用性を持ったシステムの構築
* Fargate Spotを利用したコストの削減
* ECS Fargateを使ったオートスケーリング
* CodePipelineの環境構築からデプロイまでのIaC化
* CodePipelineを使ったCICDによる自動化