# 自動化の実現方法(AWSを軸に)

最初に、AWSはそんなに詳しく無いこと、狭い自身の経験からの考えになること、をご理解下さい。

---

## 整理

まず「プラットフォーム(自動化したい既存の何か)」が

1. AWS
2. 上記以外

か、

次に「自動化」と呼んでるものが、

1. 定期実行(タスクスケジューラ等)
2. バッチ処理(パイプライン等”複数の処理をつなぐ”もの)

か、

最後に「対象」が

1. CI/CD等(プログラム・システムを構築するためにやること)
2. 業務

か、

これくらいの分類で、使うものや考え方を変えています。

---

結論的な脳内イメージは以下です。


## CI/CDかどうか

まず、CI/CDか業務か、の分類から。


大きく意識しておくべきは

1. 処理対象が「ソース」と「データ」で異なる
0. 処理対象のライフサイクル、バックアップ、信頼性設計が違う

ということ。

ここを混ぜて考えてしまった場合、「システムのデータに対する処理の信頼性」「システムのデータのバックアップ対策」などがCI/CD側の水準で設計した後「ま、いっか！」のバイアスがかかり、後に事故がおこる可能性があります。

CI/CDなら、コードに関するものなら「GitHubActions」で作りますし、AWSのプロダクトの組み合わせでインテグレーションに関するものなら、俗にいう「コード3兄弟」で作ります。

## 業務

CI/CD以外、業務で作る場合は以下のような考え方をしています。

### AWS

#### 特定時間に実行したい場合

単発かつ「既存のもの」であれば「そのAWSプロダクトに所属しているタスクスケジューラの機能」で定期実行を使います。

たとえば、ECS(Fargete)であれば、「スケジュールされたタスク」という名前の機能があるのでそれを使いますし、
Lambdaであればトリガーを選ぶ際に「EventBridge(CloudWatch Events)」というのがUIに出るので、それを使います。

そういうものが無ければ「EventBridgeスケジューラ」でキックします。

「(既存プログラムが旧サービスで)それしか使えない」等、特殊な場合は「CloudWatch Events」を使います。
しかし、AWS的には”古”く、「EventBridgeスケジューラ」を使うよう推してるようです。

さらに言えば「ECSの”スケジュールされたタスク”」機能の中身も「EventBridgeスケジューラ」なので、AWS内部でも結局全部それに寄せてる感じがします。

#### 処理を数珠つなぎしたい場合

細かいものが散ってる、またはつなぎづらいものが在る場合「AWS Lambda」でプログラミングしてつなぐのが良いかもしれません。

また、実行対象を新たに作る(既存資産ではない)場合や単一コマンドやスクリプトはあるが実行場所をあぐねてる場合「AWS Batch」を使えば良いと思います。

既存のものが多数、少しの分岐や制御、フローが明確などであれば「Step Functions」でつなぐのが良いかもしれません。

また、上記3つは「組み合わせて作る」こともでき、処理自体を多段に設計することも出来ます。

- 参考
- https://qiita.com/kazuktym/items/0ecc1dbf98c3c3623473 (定期実行のハナシも混ざってる)
- https://qiita.com/miyuki_samitani/items/6c58d107cdc86d938fe3
- https://www.sunnycloud.jp/column/20220421-01/

### AWS以外

AWSのみで完結しないもの、AWS上に無いものを使いたい、もしくはAWS&他サービスを組み合わせたい場合等の場合は、以下が検討材料になります。

ただし、AWS+Publicサービス(ローカル等外から蹴れないもの以外)を数珠つなぎしたい場合は「AWSに寄せる」も検討下さい。

#### 特定時間に実行したい場合

準備工事に「既存資産をWebAPI/WebHookにする」というものを行った状態、を前提とします。

オンプレサーバ&ローカルマシンからcron等でのキック、が一般的です。

上記の準備工事が済んでおり、「処理自体は持たなくて良い」なら、RasPIやミニPC等に「蹴ることだけさせる」のも良いでしょう。

自分の場合「大事にしたくない」「お金をかけたくない」「仕事外」が多いので、個人のアカウントで「貧者のcron」と異名を取る「Google App Script(GAS)」でWebを蹴るものを作ってます。

#### 処理を数珠つなぎしたい場合

「各種OS等の標準スクリプト」を使って「既存資産の数珠つなぎ」をします。
Linux/UNIXならbash、WindowsならDOS/PowerShell、等です。

ただ「つなぎたい対象」と考えを分け「実行制御」だけに限定します。

1コマンドに収まらないもの、特殊な蹴り方など「スクリプトだけで収まらないもの」があるなら、もうそのプラットフォームで使える「自身のメインストリームのプログラム言語」で組む、が視野に入ります。

## 総じて

どこにカテゴライズされたとしても、運用やメンテを考え「寄せる・減らす」事を考慮しましょう。

例えば、

1. AWSを使うと決めたが、タスクスケジューラとバッチで使うものをバランバランに散らす
2. AWS、外サービス、スケジューラ製品、ローカル実行と実現手段を散らかしてる

とかすると「一元化されてないので把握ができない」「メンテする人員が育たない」とかあるのでご注意を。

また「実現するものは全てAsCodeされている」ことを前提としましょう。

例として、RasPIやローカルマシン等も出てきますが、そこで「動かすために使ったすべて(設定ファイルやcron定義、キック用スクリプト等)」は、テキスト化(手動でやったものもダンプ吐き出し)されて、Version管理システムで履歴が取られている、という状態にしましょう。