Toilの撲滅 システム構成のコード化（X as Code）でチーム開発・サービス運用を効率化する

2018年4～5月開催「ブートキャンプ特別講座」の資料になります。

Transcript

1. Toilの撲滅 システム構成のコード化（X as Code)でチーム開発・ サービス運用を効率化する SOE部 RLSグループ 甲谷 悠(@yu_kabutoya) 1
2.  サービス運用とは  定型業務  非定型業務  ケーススタディ：非定型業務を円滑に行うために  サービスをリリースするということ  チーム開発におけるリクルートの現状  システム構成のリクルートの現状  システム構成のコード化  システム構成のコード化(≒構成管理)とは  構成管理を自動反映しToilを撲滅する  ケーススタディ：システム停止を伴うリリース Agenda
3.  サービス運用とは  定型業務  非定型業務  ケーススタディ：非定型業務を円滑に行うために  サービスをリリースするということ  チーム開発におけるリクルートの現状  システム構成のリクルートの現状  システム構成のコード化  システム構成のコード化(≒構成管理)とは  構成管理を自動反映しToilを撲滅する  ケーススタディ：システム停止を伴うリリース Agenda
4. サービス運用とは  我々はCS/CLへの新たな価値提供、競合優位性の維持のためにも新 しい価値を提供し続ける必要がある。  一方で、社会インフラとして世に提供したサービスを安心して利用 し続けてもらう責務も持ち合わせている。 4 「ソフトウェアエンジニアリングについては、誕生後に比べて 誕生前についての議論に遥かに多くの時間を費やすものの、 システムのトータルコストの40〜90%は、そのシステムの 誕生後に生じるものと推定されます。」 出典： O'Reilly SREサイトリライアビリティエンジニアリング Googleもシステム維持/保守の重要性を説 いているように、運用フェーズは超重要。 運用も改善をし続けなければ社会インフラ としての安心を提供出来なくなる。
5. サービス運用とは  サービス運用は「定形業務」と「非定型業務」の2つに大別可能。  定型業務はツールを活用した自動化を、非定型業務はいざという時 に備えた設計を行うことが重要。 5
6. 定型業務  定型業務は繰り返し実施される型化可能な業務。  経験則的に以下3つの業務が行われる事が多い。 6 定形業務は属人性を排除するために 「見える化」→「標準化」→「自動化」のStepで 自動化を進めていくのが一般的。 環境維持 リリース 監視/ モニタリング  複数ある開発環境(テストを行う環境)をリ リース後に整備する。  案件を世に公開する業務  アプリやインフラを利用可能にする  システムリリース後に問題が無いか、システ ム情報を確認する。 項目 実施内容
7. 定型業務：環境維持作業  環境維持作業とはローンチされたアプリやインフラ資源を開発環境 に適用する作業。  複数の案件が並行して走る事が多いため、環境によって適用する/し ないの状況が生まれるため複雑。 7 案件A 案件B 案件C テスト 環境A テスト 環境B テスト 環境C C/O C/O C/O 開発＆テスト 開発＆テスト 開発＆テスト • 案件Aの変更を 取り込みたい。 • 案件Aの変更は まだ取り込みた くない。 • 案件A、Bの変更 を取り込みたい。
8. 定型業務：リリース作業  案件のなかで作り上げてきたアプリケーション、インフラ資源を本 番環境に適用し、サービスを世に公開する作業。  システム規模が大きくなるほどリリース対象となる資源や関係者が 増えてくるため、作業負荷が高くなりがち。 ※後半でハンズ・オンしてもらいます。 8 ビルド/テスト config配置 環境配置 アプ リ イン フラ DB 稼働確認 外部公開 DDL、DML 最新化
9. 定型業務：監視/モニタリング  サービスの状態が正常な状態となっているかをチェックする作業。  これが無いとサービスが停止していても誰も気づけ無い状態になる のでとても大切。 9 リクルートの(主要な)サービスは監視/モニタリングを ツール化している。 担当するサービスの状態を一度は見てみましょう。 • 問題があれば 通知 • 内容をダッ シュボードで 確認
10. 非定型業務  非定型業務は突発的かつ型化しにくい業務。  型化しにくいが過去の知見を活かしながら実施していく必要があ る。 10 エンジニアの底力を試される技術力を高めやすい業務なので積極 的に実施してみるべき。※個人の意見です。 障害対応 問い合わせ/ 調査  発生したアラートや問い合わせから原因を究 明し問題箇所を取り除く。  各所から来る問い合わせとその調査  調査結果から障害対応につながることも。 項目 実施内容
11. 非定型業務：障害対応  サービスの一部または全部が利用できない状態の原因を特定し、そ の原因を取り除く作業。  ログやモニタリングを利用して原因を特定していく。 11 障害発生は好ましくないことだが対応自体は知見の宝庫。 障害対応を行った際には、その経緯や対応内容等をドキュメント として残し、ナレッジを残しましょう。 サイト責任者 開発担当者 電話 Slack 監視 標準監視 OS資源/MWプロセスを監視 サイト個別監視 検知キーワードを定義し監視 エメラルド監視 上記監視項目の発生状況を目視監視 電話 Slack 確認 Console 問題検知 通知 調査(分析)
12. 非定型業務：問い合わせ/調査  サービス利用者だけでなく、(APIを利用している場合などは)社内の 他サービスからも来る様々な依頼。  エンジニアまで来る問い合わせは担当サービスに対する技術的な問 い合わせがメイン。 12 ユーザー： エラー画面が出 て動かないんだ けど。 ティア1  過去事象の確認  発生内容のヒア リング ヘルプ デスク ティア2  過去事象の確認  データの確認 営業 Dir ティア3  ログ/DBの確認  ソースの確認 エンジ ニア
13. 非定型業務：実施において大切なこと  非定型業務ではどんな内容が来るか事前にはわからない。  だからこそシステムローンチまでに運用時に必要な情報を取るため の設計(≒非機能設計)が重要となる 13 性能設計 ログ設計 ディレクトリ 設計  想定アクセス数  それに基づくマシン台数  出力項目  エラー特定のキーワード  アプリが配置される先やロ グが出力される先の定義  各ディレクトリのオーナー 設計項目 最低限やるべきこと  性能劣化によってアクセス 不能となる  問題発生時に原因が掴めな い(障害時間の長期化)  エンハンス時にエラーが発 生する 定義しないと。。。
14. 非定型業務：ケーススタディ 14 とはいえ、非機能系の設計が後追いになりがち。 まともな設計を行わなかった場合にどんなことが起こるか やってみよう。
15. ケーススタディ：非定型業務を円滑に行うために  以下のような構成のサービス運営をしているあなた。  ある日、サービスデスクから「クライアント“鈴木一郎”様が接続 できない」と連絡が。  何が原因か特定できますか？ ※ログは別途送付します。 15 LoadBalancer WebServer 1 WebServer 2 ApServer1 ApServer2 DB Title:鈴木一郎(id:30001)さんから架電 Time:10:30分前後 Desc：ボタンを押したらエラー画面が出 て動かない。
16. ケーススタディ：非定型業務を円滑に行うために  このケーススタディでは答えはありません。 (原因の特定を求めていません。)  ただ、実業務では今回のような(ほぼ)ノーヒントの問い合わせが来 る事があります。  その際に素早く/適切な原因究明ができる仕組みづくりの大切さを感 じてほしいです。 16 システム構成を シンプルにする？ ログにエラーが吐かれたら 連絡する手段を作る？ 障害が起きない品質を 作り込む？ ログをまとめて 見れるようにする？ • 二人一組になってどうすれば原因究明を行いやすくなる か話し合いましょう。(15分) • 各組みで発表してもらいます。(15分)
17. サービス運用とは：まとめ  サービス運用には定形/非定型がある。  定形業務は自動化を行って誰でも/いつでも実施できる仕組みを用意 しておくことで、サービス開発のリソースを「生産的な」ものに多 く割り当てることができる。  非定型業務は品質維持のためにも事前に設計しておく事が重要(俗に 言う非機能設計が重要) 17
18.  サービス運用とは  定型業務  非定型業務  ケーススタディ：非定型業務を円滑に行うために  サービスをリリースするということ  チーム開発におけるリクルートの現状  システム構成のリクルートの現状  システム構成のコード化  システム構成のコード化(≒構成管理)とは  構成管理を自動反映しToilを撲滅する  ケーススタディ：システム停止を伴うリリース Agenda
19. サービスをリリースするということ  サービス運用のなかで「リリース業務の負荷が高くなりがち」と説 明した。  なぜリリース業務の負荷が高くなりやすい構造なのか、開発体制と システム構成から紐解いていく。 19
20. チーム開発の現状  システム規模が大きくなるほど役割ごとにチームが分かれてくる。  ディレクター(MP)とエンジニアだけでなく、エンジニア内部でも別 れてくることが多い。 20 開発全体責任者 (主にGM) 開発統括 テックリード クライアント アプリ カスタマ アプリ バッチ アプリ 営業支援 アプリ スマデアプリ 運用 QA UI/UX 基盤 統括 領域 担当 領域 横断 エンジニアの チーム設計例
21. チーム開発の現状  エンジニアのチームが複数になってくることとサービスの成長には 相関関係がある。  そしてサービスはその成長の段階に応じて求められてくる事が異な る。 21 規模 導入期 成長期 成熟期  まずはフィジビリ  早く世に新しいものを  競業に勝つ  新しい機能をどんどんロー ンチ  競合劣位の防止  機能提供に加えて、 サービス品質をより高める フェーズ マインド
22. チーム開発の現状  サービスの成長によって求められるものが異なるのと同様に、 開発内部のチームそれぞれによっても守るべきものが異なってくる。 22 クライアント アプリ カスタマ アプリ バッチ アプリ 営業支援 アプリ スマデアプリ 運用 QA UI/UX 基盤 領域 担当 領域 横断 担当 守るべきもの  機能追加の速度 (いいものをより早く) →変化へのプレッシャー  機能追加の品質 (安全、安心に) →安定へのプレッシャー
23. チーム開発の現状  サービス成長に伴ってシステムの大規模化。  初期段階で想定していたリリース方式は陳腐化し、アドオンの要素 が増えることでリリースという作業の負荷が増加してしまう。 23 CIツール等でジョブ化する こと「だけ」を実施して サービスの成長を見越さなけ れば陳腐化してしまう。 リリース設計 (初期) • 機能追加。 • 機能追加。 • 機能追加。 • 体制変更。 リリース設計 (現在) アドオン要素 アドオン要素
24. チーム開発の現状：(参考)あるサービスの場合  あるサービスの運用フェーズにおける作業割合を紐解くとリリース 作業の占める割合がとても多くなっていた。 24 2% 環境切り替え 16% リリース 52% 問い合わせ 22% 調査 8% 作業状況  環境切り替え(開発環境切り替え)にて他チームとの作業 依存があるため環境利用までに最大1Wのリードタイム がかかる構造。  リリース作業にて述べ2W人員張り付きが必要。  リリースリハリハ、リハ、本番と計3回のリリース が月次で行われている。  リリース作業にて他チームとの作業依存と利用する ツールの多さから一気通貫での作業実施が出来な い。  (上記に紐づき)手順書の作成、レビューといった付 帯作業も増加。
25. チーム開発の現状：(参考)あるサービスの場合  そのサービスのリリース作業の作業内訳を見てみるとアドオンに よって作業負荷が増加していた。 25 作業名 概要 自動化 アプリビルド WARファイルの作成 ◦ 資源配置 WARファイルのAPサーバ への配置 ◦ メンテ画面配置 Sorryページの設置 × DDL適用 DBオブジェクト更新 × コンテンツminify JSファイルのminify × コンテンツ配置 JS/imgファイルのAPサー バ配置 ◦ コンテンツ配置(CDN) JS/imgファイルのCDN キャッシュクリア × 他シスデータ連携 他シス向けDB更新 × Cacheサーバデータ再配置 Redisへのデータ更新 × 新しい機能の追加や、関係 者の増加によって、当初想 定したリリースがどんどん 肥大化することがある。
26. チーム開発の現状：まとめ  サービスの成長につれ規模だけでなく開発体制(特性)も変化する。  その変化を見据えたリリースの仕組みを作る必要がある。  仕組みづくりではリリース自体の自動化を目的とせず、リリース対 象と作業両方のコード化/構成管理を行う必要がある。 26 高負荷運用業務(リリース業務) DB変更 手順作成 DB変更 アプリ 手順作成 JP1 リリース アプリ リリース リリース 内容確認 JP1 手順作成 MW変更 手順作成 作業 内容確認 MW リリース ボトルネック 他シス関連 リリース 後続作業に依存 が高い 作業時間が長 く、環境数に応 じて線形に増加 する ボトルネックを特定し、リリースの仕組みを作る。
27. システム構成の現状  リクルートの大規模サイトの多くが「RAFTEL」という社内PaaSを 利用している。  社内PaaSという特性上、利用するサービスの最大公約数的なシステ ム構成が提供される作りとなっている。 27 最大公約数であるがゆえに常に最新には追随出来ない。 個別のシステム構成を取る場合にはRAFTEL/サービス双方に一定 の負荷がかかる。
28.  RAFTEL上で構築される最大公約数的な構成。  全ての機能は複数台で可用性を高めている。 システム構成の現状 28 Web Apache nginx AP Tomcat Search Solr DB Oracle Batch JP1  静的コンテンツ表出  利用者の制御/バランシング  アプリケーション配置/実行  全文検索  データ保存(CS系のデータ保存)  リレーショナルDB  データ保存(CS/CL両方のデータ保存)  バッチ実行制御  エラー発生時の通知 構成 担当する役割
29. システム構成の現状  RAFTELはPaaSであるがオンプレミス環境に構築されている。  オンプレミスの特性としてHWの調達も自前で行う必要があり、 パブリッククラウドに比べるとリードタイムがかかる。 29
30. システム構成の現状  Rのサービスの基本はリボンモデル。  多くのサービスはこのリボンモデルにもとづいて設計される。 30 Action Customer Client カスタマ提供価値 クライアント提供価値 社会提供価値 カスタマの多種多様なニーズを 満たしたり、新たな気付きを与 えること クライアントのサービスをカスタマ に適切に届けること カスタマとクライアントのベスト マッチングを最大化しつつ、事 業収益を上げること
31. システム構成の現状  リボンモデルではクライアントとカスタマのマッチングを行うサー ビスが主。  システム構成としてデータストアに対する読み取りと書き込みを個 別のアクターが実施する(共用する)場合が多い。 31 Action Customer Client データストア 入稿/登録 検索
32. システム構成の現状  加えて主要サービスは本誌(紙媒体でのカスタマ集客)を行う機能を 持つことが多い。  これによってアクター単位のシステムが複数必要となる。 32 Action Customer Client データストア 入稿/登録 検索 営業支援 店舗管理 （CL管理） じゃらん/HOT PEPPER /Townwork等 バッチ
33. システム構成の現状  システム構成は。  大規模サイトは現状RAFTELの利用が多い。  RAFTELはリードタイム短縮のために開発環境と本番環境の構成 が異なる場合が多い。  リボンモデル実現のためにデータストア層を共存する事が多い。 33 システム構成としては一般的なWeb/Ap構成が多いが 関連システムが多くなり依存関係が発生。 これにより、リリース作業に依存関係が発生する。
34. システム構成の現状  (開発体制と同様に)システム構成もサービスの成長に伴って変化。  変化の起因は技術要素の追加、や新機能の導入(アーキテクチャの追 加)等様々。 34 Web Apache nginx AP Tomcat Search Solr DB Oracle Batch JP1 Cache Redis ElasticSearch Node • 新しい技術要素の 追加 • 新しい機能の追加 構成
35. システム構成の現状  サービスの成長に伴って変化するのは機能だけではなく、サーバ台 数も変化する。  アプリケーションのチューニングだけでは対応しきれない場合等、 サーバのスケールアップ/アウトでサービスの成長を支える。 35 アクセス数とサーバの処理能力は 相関関係が強い。 サービスの成長に伴ってアクセス スは増加する傾向がある。
36. システム構成の現状：まとめ  システム構成の役割や同じ役割のサーバはどんどん追加される。  そして、サービスを構成するサブシステムが多く、依存性も高い。  リリースを行う際にはサブシステム間の依存性を考慮と、スケール のしやすさ(複数サーバへの配布が可能な構成)を考慮する必要があ る。 36 Web Web Web Web Web AP Web Web Search Web Web DB AP リリース DB リリース Search リリース Web リリース リリースツール 役 割 単 位 の サ ー バ に 一 斉 配 布
37. サービスをリリースするということ：まとめ  サービスはどんどん成長していく。  成長に伴って開発体制/システム構成が変化していく。  そのため、リリースの一部のみを自動化したとしてもアドオンがど んどん増える。  だから、構成管理とリリースツール双方を考える必要がある。 37
38.  サービス運用とは  定型業務  非定型業務  ケーススタディ：非定型業務を円滑に行うために  サービスをリリースするということ  チーム開発におけるリクルートの現状  システム構成のリクルートの現状  システム構成のコード化  システム構成のコード化(≒構成管理)とは  構成管理を自動反映しToilを撲滅する  ケーススタディ：システム停止を伴うリリース Agenda
39. システムのコード化とは  前章で説明した内容を踏まえ、大規模環境を見据えたリリースに対 する要件は以下となる。 39 • 構成管理を取り込んだリリースであること • 各サブシステム間のリリースに対する依存関係を 表現できること • 本番環境と開発環境の差異を吸収できる事 • スケールが容易であること。 「構成管理」についてもう少し具体的に見ていきます。
40. 構成管理とは  構成管理とは「リポジトリによる一元化」と「環境情報とコードの 分離」が出来た状態で管理すること。  Github(git)やMerculial等によるソース管理を継続的に行っている状 態を指す。 40 構成管理① ソース自体の管理 構成管理② テストスクリプトの管理 構成管理③ 環境情報の管理
41. 構成管理とは：技術選定  構成管理はあらゆるチームが関連するものとなる。  全てが一元管理されなければ陳腐化しアドオンが増える  そのため、技術的な先進性よりもエンジニアの手に馴染む(ある程度 枯れている)技術要素を選択する必要がある。 41  構成管理のようなサービス運用の目的は皆に利用し続けてもらうこ と。  サービスの機能と異なり利用者の多い技術要素を選択する。 構成管理 (サービス運用) 既存技術  利用者が多く、キャッチアッ プ負荷低  導入がスムーズに行き、継続 利用が見込める。 新技術  キャッチアップ負荷高  既存の技術と親和性が低い場 合も  陳腐化させない見極めが必 要。
42. 構成管理とは：環境依存の分離  コード(振る舞いを記述したもの)は1ファイルのみを管理すべきであ る。  そのため、環境に依存する情報と、コードを分離して管理できる必 要がある。 42 開発 検品 本番 リリース 構成管理(環境情報同梱) コードA 開発情報 コードA 検品情報 コードA 本番情報 開発 検品 本番 リリース 構成管理(環境情報分離) 開発情報 コードA 検品情報 本番情報
43. 構成管理とは：テストスクリプト  記述したコード(振る舞い)は常にテスト可能な状態を保つ必要があ る。  コードの対となるテストもスクリプトとして管理できる必要があ る。 43  スケールしづらい (アプリ改修時にテスト範囲が限定)  影響範囲が可視化されない 手動のテストだと  テストを自動化して品質とスピー ドを維持するべき。  いつでもテスト可能とするために コードと合わせて管理するべき。
44. 構成管理とは： (参考)管理すべき要素  管理対象はアプリケーションのソースコードだけにとらわれがちだ が他にも様々ある。 44 ディレクトリ マスタデータ (DML) DDL ジョブ定義 (JP1) アプリ 資源 JIRAチケ (手順) JIRAチケ (添付) OB ER 検品環境 GhE telnet sqlplus sqlplus JP1 Mgr telnet TeamCity telnet リリース対象 資源管理方法 作業方法 Conf 各環境 (一部GhE) telnet 資源の管理方法が構成管理に 従っていない場合、作業方法が 人手を介したものに依存しがち にになる。
45. 構成管理とは： 責任範囲の切り分け  構成管理対象を1つの仕組みだけでリリースしようとすると破綻す る。  用途に応じた利用ツールの変更と透過的なリリース実行を多段的に 構成する。 45 リリース資源 の受け渡し (構成管理) リリース資源 のビルド (ツール) リリース資源 の環境配置 (リリース) マスタデータ (DML) DDL ジョブ定義 (JP1) アプリソース MW Conf ディレクトリ config file YAML YAML YAML Java YAML Ansible (Python) Liquibase (Java) 独自ツール (Python) Maven (Java) 独自ツール (Python) Jenkins (build pipeline) 【ポイント】 1. 変更の多い内容はシンプルな 記述で構成管理 2. ビルド時には管理の内容に 応じた適切なツールを採用 3. リリース(運用時に操作する ツール)は透過的に実現でき る技術を採用 全体は複雑でも各レイヤはシンプルに
46. 構成管理とは： HOT PEPPER Beautyでの事例  個々で具体的に何を/どう管理しているのかをHOT PEPPER Beauty での取り組みをベースとして紹介する。 46 • 構成管理すべき内容とし てこの項目が含まれが、 必ずしも全てを管理しな くとも良い。 • 変更の発生頻度が高い物 を選んで管理するのが良 い。
47. 構成管理とは： HOT PEPPER Beautyでの事例  インフラ系の配布にはAnsibleを利用。  OSやNWレイヤはRAFTEL側で管理し、それより上の層はサイトと してAnsibleを利用している。 47
48. TeamCityでラップ 構成管理とは： HOT PEPPER Beautyでの事例  Javaアプリの配布にはMavenを利用。  オンライン、バッチともにJavaで実装されているものが多い  MavenをキックするためにJetBrains社のTeamCityというツールを 利用。 48 Maven compile test package deploy リポジトリ コード テスト スクリプト Prpirties • リリースに関連する作業は Mavenだけで完結可能 • しかし統一したUT環境を提供 するためにTeamCityでラップ している ※利用当時他のCI/CDツール ではパフォーマンスが出ず TCを利用。
49. 構成管理とは： HOT PEPPER Beautyでの事例  バッチ(JP1) の配布には独自ツールを利用。  前述の透過的なリリース実現のためにシンプルなツールを提供。 49 開発環境 検品環境 本番環境 Exp/Impツール JP1定義 開発情報 検品情報 本番情報 • JP1定義自体のテストは 出来ない。 • 開発環境で作られたもの をベースとして利用。 • 開発環境で作られたもの に各環境の固有情報をバ インドし利用。
50. 構成管理とは： HOT PEPPER Beautyでの事例  DBのテーブル定義(DDL)の配布にはLiquibaseを利用。  DDL自体はYAML形式で記述。 50
51. 構成管理とは： HOT PEPPER Beautyでの事例  全体の実行状態の管理にはJenkinsを利用  オーケストレーションツールとして利用  Jenkinsのジョブ自体もコードとして管理しリリース時の依存関係を 柔軟に変更可能としている。 51
52. 全体のまとめ  サービス運用には非定型業務と定型業務が存在  非定型業務は何が起こるのかを想定しながら事前設計が重要  定型業務はツールを活用した自動化を推進することが重要  特にリリース業務は陳腐化を起こしやすいため構成を分離する個 を検討すべき 52 ここからはリリース業務を体験してもらう ハンズオンの説明です。
53. 構成管理を自動反映しToilを撲滅する ハンズオントレーニング  ここまで伝えてきた構成管理を実際に利用しながら自動化との連携 を理解してもらいます。  全てをこなすことは難しいので以下のツールを駆使しながらリリー スを実行してもらいます。 53 Ansible  Webサーバのconf書き換え  今回はメンテナンスページへの誘導を担当 Liquibase  DDLの更新  今回はテーブルに新たなカラムを追加 Maven  アーティファクト(WAR)の作成  リリース向けのアプリケーションを作成する Jenkins  上記のツールの実行と制御
54. ケーススタディ：依存関係のある機能のリリース  担当している「ToDoリストサービス」のに新機能が追加されること になりました。  今回はDBに大きな変更が入るためメンテナンスページに飛ばす必要 があります。 54 Web (nginx) Ap (Tomcat) DB (Oracle) Jenkins ① rewrite設定でメンテページに誘導する ② テーブルにカラムを追加する ③ 修正版のアプリを配置する ④ 内部動確で全体的な動作確認 ⑤ 問題なければメンテページを元に戻す (外部公開する。) 単純なシステム構成でもDBの変更が伴うとリリースが複雑 になる場合が多い。
55. 構成管理を自動反映しToilを撲滅する ケーススタディ接続情報 55 1.踏み台ログインssh $ trainingXX@bc-ssh.rtc-rcloud.jp -p 443 2. training_keypair.pemを入れてssh通信する .sshディレクトリ作りpemをそこに置く ※training_keypair.pemのパーミッションは400で $ ssh -i .ssh/training_keypair.pem ec2-user@EC2のIPアドレス 3.tomcatの起動 $ sudo /usr/local/tomcat8/bin/startup.sh 4.nginx confのservernameを変更しリロード $ sudo vi /etc/nginx/conf.d/training.conf → server_name 13.231.165.22; #この行のIPアドレスを自分のEC2のアドレスに！ $ sudo service nginx reload 5.ブラウザからの起動確認 http://EC2のIPアドレス/ap/ 最後に、各自事前準備として作業を実施して下さい。 また、気になるポイントがあれば講師まで。