今まで現場で学んできたことをもとにサーバーレス開発についてまとめました。

サーバーレスで開発をしていく上で導入すると便利なサービスやどんな時に役立つかなどを中心に書いていきます。

前提として、今回はアプリケーションレベルでの話をしていきます。

書き始めたら内容が結構膨らんだので概要を記載します。

・CI/CD

・DB

・ログ

・監視

・バッチ

・ブランチ

・サーバー

・Datadog特集

・最後に色々と

### CI/CD(Jenkins、CircleCI)

サーバーへのデプロイなども含めてパートナーに開発業務を手伝ってもらいたいが、サーバーに入れるのは一部の人のみに制限したいということありませんか？

そういう場合にこれが役に立ちます。自動ビルド・自動テスト・自動デプロイを行ってくれます。

### DB(redash)

最近はデータ集計をするためにビジネス職の人でもSQLを書く人が増えていると思います。

しかしビジネス職の方にDBの接続情報を渡して、SQLを叩いてくださいだと管理が面倒ですし、DBに異常を起こしてしまう可能性もあります。

そんな時にredashを利用すると良いです。

redashはchromeなどのブラウザ上でSQLを叩けるので利用者はサーバーを意識しないでもデータ集計ができます。

### ログ(Datadog)

ログが見れないと開発・運用・保守の作業はできません。

CI/CDで記載したように、サーバーに入れる人は制限したい。それが本番環境なら尚更。しかしログは基本サーバー内でしか見れないけどどうすれば良い？

そんな問題を解消するのがDatadogです。

Datadogに関してはDatadog特集を書いたので見てもらえればと思います。

### 監視(Datadog、slack、pagerduty)

サーバーなどの異常を検知して、即対応ができるようにします。

通知をする上で一緒に連携させておくと便利なのが、slackやpagerdutyなどですね。

Datadogで異常を検知してslackにアラートを飛ばしたり、pagerdutyと連携して電話をかけたりなどします。

Datadogに関してはDatadog特集を書いたので見てもらえればと思います。

### バッチ(Rundeck)

運用保守でバッチを手動で実行してログを見て、次のバッチを実行してなど、バッチの管理が面倒に思ったことはありませんか？

そういう場合にはこれが役に立ちます。

バッチの管理、ログの確認などがUIで確認できるので、運用保守の効率が向上します。

### ブランチ(GitHub)

一般的なソースコード管理ツールですね。多くの開発者が利用しています。

### サーバー(ECS、Fargate)

dockerなどのコンテナを利用することでサーバーの構築や保守などを意識することなく、サーバー上でプログラムを実行できます。

サーバーレス開発といったらこれをイメージする方も多いと思います。ならEC2を利用していたらサーバーを意識せずに開発は無理なのかというと実はそうでもないです。

EC2を利用してサーバーを意識せずに開発・運用・保守をするには今まで挙げたツールを上手に利用することで実現できます。

もちろん初期の構築時ではサーバーに入って作業が必要ですが、一旦仕組みさえできればサーバーを意識せずに開発できるようになります。

用途としては、パートナー企業は本番サーバーへ入れないようにしたいなどの要望がある場合などですね。

### Datadog特集

今回記載していった中で特に取り上げたいサービスがあるので特集として記載しました。対象サービスは監視ツールであるDatadogです。

このサービスは私が今の現場で開発・運用・保守を行う上で１番利用頻度が多かったサービスです。

具体的にどんなところが良いのか質問形式でまとめました。

CPUの利用率をみたい？

→「メトリクス」の機能で確認できます。メトリクスではリソースの利用率の推移を時系列で確認できます。他の見方もできますが割愛します。

サーバーがダウンしたりCPU利用率が跳ね上がったりしたら異常として検知したい？

→「モニター」の機能で検知できます。しかもslack連携をすれば、slackに連絡を飛ばせますし、pagerdutyと連携すれば担当者へ電話を飛ばせます。

プロセスごとに利用率などを計測したい？インフラのスペックを確認したい？

→「インフラストラクチャ」の機能でできます。この機能はインフラの設定や利用率などを確認するのに利用できます。

APIの各機能の処理時間を計測して処理速度の改善を行いたい？

→「APM」の機能で処理速度の計測ができます。他にもAPIの中で発行されたSQLクエリの内容の確認もできます。

定期的に確認するメトリクスを毎回作成するのはめんどくさい？

→「dashbord」機能を使いましょう。サービス単位でメトリクスを見れるようにしたいなどで利用すると便利です。

RDSなどのAWSサービスで再起動などが起こったら見れるようにしたい？

→「イベント」機能を使いましょう。RDSが内部で再起動されてたけどいつされたんだ？など把握できます。k8sなどのコンテナオーケストレーションツールを利用している方は、ワーカーノードがどんな動きをしているのか把握するのにも使えます。

質問形式で色々書きましたが、最後にDatadogの良さを記載して終わりにしようと思います。

開発・運用・保守のフェーズでログやメトリクスなど見たいものがあればかなりの割合でDatadogで確認できます。

これの１番のメリットは開発・運用・保守のスピードが格段に上がることです。

なぜかというと、多くのクラウドサービスがDatadogと連携しているので同一プラットフォームで様々な情報が取得できるためです。

例えばですが、事業部ごとにAWSサービスを利用していて横断的にログを確認したい時でも他事業部のAWSアカウントをもらってDatadogを見る必要はなくなりますし、

ほとんどAWSだけど一部をGCPやAzureにしているなどの場合もDatadogでログが確認できるのでわざわざサービスごとの利用方法を意識しなくてもログを確認できます。

あと個人的な感想ですが、cloudwatchでログを取得したり、メトリクスを見るのは面倒だなと感じることが多いのでできればDatadogで確認したいですね。。

### 最後に色々と

最初この記事をかき始めた時は書くこともそんなないから10行くらいで終わるかもなと思っていたのですが、書き始めると思ったよりも量が膨らんだので、現場で色々学びがあったのだと実感できました。

今後も定期的に現場で学んだことを書く機会を儲けるのも良いなと思いました。

以上です。