S先輩にきいてみたっ！ - Amazon Web Serviceのデプロイメントマネジメント - 第4話 自動

[第１話](http://qiita.com/ukiuni@github/items/c82cf2b0b3d16ab7c2a0)、[第２話](http://qiita.com/kazuqqfp/items/1e326e1452468c33800b)、[第３話](http://qiita.com/imafuku/items/b40a5a9b049c38fdbd48)はご覧になっていただけましたか？
第４話のテーマは「デプロイメントマネジメント」です。
なお、ストーリーはフィクションであり、実在の人物・団体とは一切関係ありません。

#4話 自動

「まずいことになった」

　ある金曜日の19時頃、Aはぼそっとつぶやいた。 
Aは太字で"Internal Server Error"と表示されたブラウザを見つめていた。 
もしかしてと思い何回かキーボードのF5キーを押してみたが帰ってくる結果は変わらなかった。 
周りを見渡したAは直ぐに正面を見る。

「さすがにもう誰もいないか・・・」

　Aは半年前にモブ先輩から社内機器貸出システムの保守運用を引き継いでいた。 
システムとしては小規模であるが最近、他部署でも使われだしユーザは100人になろうとしていた。 
開発方法からテスト方法、リリース手順等一通りできるようになったなと密かに自信を持っていた。

「あぁ〜　これモブ先輩にお願いした所のエラーだ　自分ではわからないぞ」

　特殊なソフトを使っている箇所があり、その部分だけいつもモブ先輩にお願いしていたのだ。 
モブ先輩、今は九州出張中だ。 
その先輩からもらった設定変更内容やリリース手順が書かれたメールをもう一度確認してみる。

「テスト環境にリリースした時にはうまくいったのになぁ」

「でも今まではうまくいっていたのに　何が違うのだろう・・・」 

もう一度作成したチェックリストを見直してみる。

「A君　どうしたの？」

「えっ　まさかわざわざ駆けつけてくれたんですか」

「なんのこと？　今ちょうど打ち合わせが終わって戻ってきたんだけど」

「すいません　助けてくださ〜い。」

　ナイスタイミングで戻ってきたS先輩に事情を話す。 
先輩と一緒に確認したところ、手順を一つ飛ばしていることが分かった。 
リリースをやり直した後、動作確認も終わりリリース終了メールを配信。 
20時50分　ぎりぎりだった。

「S先輩　ありがとうございました。本当に助かりました！」

「このシステム　AWS使っているんだよね」

「はい　EC2とRDSを使っています。」 

システム構成はEC2内にTomcatを立てそこにJavaアプリケーションを配置。 オートスケーリングできるようにしテスト環境、本番環境の2環境用意している。 またソースコードはGitHubに置いてある。

「いつもどうやってデプロイしているの？

「えーと　ローカル環境でwarファイルを作成してからEC2にアップロードしてますけど」

「ふーん　テストは？」

「はい　モブ先輩が作ってくれたシェルをローカルで起動させて各自テストを行ってます」

「なるほどー。そういう感じだと環境構築もAWSのコンソールから作ったの？」

「そうです。　モブ先輩が作ったものをそのまま今でも使っています」

「今回の改善要素は今A君が話した中にあると思う！」

「自動化しないのはリスクだということ！」

S先輩の言う自動化というのは何だろう？　 warファイルを作るのもシェルで自動化しているし、テストもそうだ。

困惑した顔のAの隣に座るとS先輩はそのリスクを一つ一つ指摘し始めた。 
手順書がメンテナンスされない　→　イレギュラーな手順をメールで受けとっている 
手作業で間違う　　　　　　　　→　手順を一つ飛ばした 
職人芸への依存　　　　　　　　→　モブ先輩にしかわからない部分がある 
長時間作業　　　　　　　　　　→　リリースに2時間掛かっている

結果として 
コスト増大 チェックリストが増える 
手作業なのでリリース失敗、戻し失敗が起こりやすい
→　リリースに自信が持てない

「はぁ　引き継いだままの手順でやっているんですけど・・・」

「モブ先輩は自動化コストを考えたんだと思う。今は状況が変わっているでしょ」 

S先輩は丁寧にコストについて説明してくれた。 
それは 
自動化にはコストがかかる 
達成まで時間もかかる 
手作業と自動化した場合のコストを比較して判断する 
小規模なサイト、使い捨てのアプリ、納品したら終わりのモノは慎重に判断する 
ということだった。

「なるほど　当時は小規模なサイトで使っている人も少なかったから、コスト比較をして自動化しなかったんですね！」

「きっとそうだと思う」

「せっかくAWSを使っているのだからもっと活用したほうがいいよ 　じゃあ　このあたりのサービスを調べてみて！」 

そういうとS先輩は紙にいくつかのサービス名を書き出した 

|            |  サービス名   |  
|:-----------|------------:|
| コーディング | Code Commit  |  
| Build→Test | Code Pipeline |  
| Deploy→Provision→Monitor | Elastic Beanstalk,OpsWorks |  
| Deploy  | CodeDeploy | 
| Provision | Cloud Formation | 
| Monitor | Cloud Watch | 

「わかりました　ちょっと調べてみます！」 

さっそく自宅に帰ったAはポケットから紙を取り出しサービスを調べ始めた。

「へぇー　Cloud FormationってTemplateを使ってAWSのリソースを自動で生成できるんだ　インフラの構築もコードで書けるということか」

Elastic Beanstalk

「うん　Elastic Beanstalkを使うとよさそうだな」

「特徴としてはこんなところかな」 

AはElastic Beanstalkの特徴を確認してみた。 

定番構成の構築
・デプロイの自動化サービス 利用できるAPIの制約
・処理時間の制約はない ロードバランサ—
・オートスケーリングも可能 実行環境の設定が楽 
・バージョン管理も出来る 複数環境の構築が可能

「ちょっとやってみよう」
 https://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/GettingStarted.html

新しいアプリケーションの作成リンクからアプリケーション名を入れた後、新しい環境ページへ

「ウェブサーバとワーカーを選ぶのか　選ぶのはウェブサーバだけどワーカーって何だろう・・・」 
https://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/concepts.concepts.architecture.html?icmpid=docs_elasticbeanstalk_console#concepts.concepts.architecture.worker

「へぇー　ワーカーはバッチ処理をする場合に選ぶとよさそうだな。」

環境タイプページへ 
「選べる定義は意外に多いんだな。　今回はTomcatだな」

 1) Node.js
 2) PHP
 3) Python
 4) Ruby
 5) Tomcat
 6) IIS
 7) Docker
 8) Multi-container Docker
 9) GlassFish
 10) Go
 11) Java

Select a platform version.
 1) Tomcat 8 Java 8
 2) Tomcat 7 Java 7
 3) Tomcat 7 Java 6
 4) Tomcat 7
 5) Tomcat 6

 「環境タイプのところでオートスケーリングを選べるんだな」

アプリケーションバージョン

 「ここでwarファイルをアップロードすればいいんだな」

その後、環境情報、その他のリソースでRDSをチェック
構成の詳細でEC2の情報を入力した。RDS設定をした。

 「以前はEC2、RDSのそれぞれのコンソールで作っていたからいっぺんに出来るのは楽でいいな」

翌朝

「S先輩　Elastic Beanstalkって楽でいいですね」

「そうね　Elastic Beanstalkは今回のシステムにマッチしていると思う」

「で　どうやったら自動化できるか考えた？」

「そうでした。　自動化でしたよね　忘れてました。」

「Elastic Beanstalkはコマンドからも使えるのよ」

 Elastic Beanstalk コマンドラインインターフェイス（EB CLI）のインストール 
https://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/eb-cli3-install.html#eb-cli3-install-linux EB

 CLI による Elastic Beanstalk 環境の管理
 http://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/eb-cli3-getting-started.html

 EB CLI コマンドリファレンス
 http://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/eb3-cmdcommands.html

 gitとの紐づけ
 https://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/eb3-cli-git.html

「なるほど！　EB CLIを使えばコンソールからデプロイしなくてもよくなるのか」

 Aは自席にもどって自動化の仕方を考えてみた。

GitHubからソースを持ってきて、warファイルを作成
 EB CLI:```
 git deploy テスト環境名　
 ``` でデプロイを実施

 そのあとモブ先輩作成のシェルでテストを実施
 
 テストがOKだったら
 EB CLI:```
 git deploy 本番環境名　
 ```でデプロイを実施
 
 そのあと本番でもモブ先輩作成のシェルでテストを実施
 OKなら完了メール送信、NGだったらエラーメール送信
 エラーの場合はS3に保存したある前バージョンをデプロイして戻す。

「自動化ツールはJenkinsがいいかな」

 AはS先輩の助けを借りながら作業に取り掛かった。 試行錯誤を繰り返し、自動化を実現した。

ある金曜日の19時20分頃

 「お疲れ様でした。」

 Aはメールが届いているのを確認した後、かばんを持って会社を出た。
 リリースに掛かった時間は20分だった。

「前回かかった時間が110分だから、90分も短縮できたのか。1時間30早く帰れる！」 いつもよりも幾分混んだ電車にのって、Aは帰宅した。 「さて、今日も勉強するか。ん？今日勉強する章は『3.0 デプロイメントマネージメント』！？S先輩はそれを見越して、あんなに丁寧に教えてくれたのか。。。。」  S先輩の思いやりに感謝しつつ、今回の事例をレポートにまとめるAであった。