全てのはじまり
kyntk 「本番サーバーを触れる権限が欲しいです」
先輩 「インフラの設計と構築ができないと権限をあげることはできないなー。 今度のサービスのインフラ設計と構築を勉強のためにやってみれば？
」
kyntk 「やります！！！（できるとは言っていない） 」
はじめに
Ateam Lifestyle x cyma Advent Calendar 2018の16日目は、株式会社エイチームライフスタイルの新卒2年目Webエンジニア @kyntk が担当します。
普段はバックエンドがメインですが、弊社Webエンジニアはフロントからインフラまで広く開発を行うことができ、今回はインフラ構築を任せてもらいました。
今回の記事では、初めてのインフラ構築で試行錯誤しながら学んだことをまとめました。
具体的にどのような手順で設計、構築したかという話はもっと詳しい記事がたくさんあるので今回はしません。
色々未熟な点が多いですが、気になった点がありましたらコメントしていただけると嬉しいです。
対象者
インフラ設計・構築をしたことがない人を対象としています。
この記事を読んで、私の経験から学んだことを活かしてよりスムーズにインフラ構築ができるようになればと思います。
今回構築した環境
今回は新規のメディアサービスを立ち上げるタイミングで、そのサービスを動かすインフラを構築をしました。
アプリケーションはRailsで、Dockerを使用しています。
構成は以下のようにしました。（一部省略をしている部分があります）
【 設計フェーズ 】
設計フェーズでは以下のようなことを行いました。
- 要件の整理
- インフラ・ミドルウェアの大枠決定
- インフラ構成の案出し、決定
■ 設計フェーズで重要だったこと
1. アプリケーションの特徴を把握すること
どのようなアプリケーションを動かすのかをきちんと把握することが必要です。
例えば、アクセス数はどの程度なのか・急に跳ねることはあるのか、キャッシュは必要かといったことです。
「アプリケーションにはこのような特徴があるからこうする」のように、根拠が必要になるので、きちんと理解をしておくことが必要です。
これにより、ツール選択の目的を明確にすることができます。
2. メリット・デメリットの両方を検討すること
ミドルウェアなどに関して複数のものを比較する時には、メリットだけでなくデメリットも考える必要があります。
なぜなら、デメリットが大きく、実際には選択できない可能性もあるからです。
私はメリットの部分ばかりを比較しがちでした。
例えばCloudFrontを導入したいと考えたときに、費用や構築工数などの考慮が抜けていました。
実際に決定をするときは、そのデメリットが克服可能で、それに勝るメリットがあるのかどうかを比較する必要があります。
3. 方向性がずれていないか、細かく確認すること
「今から○○について考えようと思っているのですが、こういうことであってますよね？ 」
「こうしたいのですが、どう思いますか？」と細かく確認することで手戻りが少なくなります。
特に初めてのことをやる時は、相手が考えていることとのズレが発生しやすくなります。
例えばネットワークの設定などで、
「相手は既存のものを使う想定だったのに再度一から考え直して、余計な工数がかかってしまった」
といったことは、先にコミュニケーションをとっておくことで防げるはずです。
4. 社内のエキスパートには前々から情報共有をしておくこと
インフラやその分野に詳しい経験豊富な先輩には早い段階から状況を伝え、知ってもらうということが必要です。
なぜなら、それまでの背景や決定してきたことを知っておいてもらうことで、相談したいと思った時にスムーズに状況を理解をしてもらえるからです。
初めは自分で情報共有ができていなかったのですが、他のメンバーが情報を伝えておいてくれたおかげで、背景をすぐに理解してもらい、構成についてアドバイスをもらうことができました。
その後、構築フェーズに移ってもサポートをしてもらうことができました。
【 構築フェーズ 】
次は構築フェーズです。
以下のようなことを行いました。
- Dockerfileの作成
- S3やElastiCache、RDSなどのAWSサービスの構築手順書作成
- 上記手順書に沿って構築（ECSは最後に構築）
- アプリケーション側にデータベースなどの設定を記述
- webサーバの設定
- デプロイ設定
- アラートの検知設定（CloudWatch、ElastAlert、Sentry）
■ 構築フェーズで重要だったこと
5. 手順書を作ること
S3やRDSなど、構築するときには細かい設定が必要になります。
それぞれの設定の詳細や、構築手順をまとめておき、きちんとレビューをしてもらうことが重要です。
また、サーバ内やデータベース内で打つコマンドなども先にまとめておきます。
特に失敗した時どうするか考えて手順を考えておくと、実行するときに焦らずに済みます。
6. 詳しい人と一緒に構築すること
今回、初めて業務でAWSのコンソールを使いました。
そこで間違った設定をしないように、詳しい人の時間を30分押さえて、同じ画面を見ながら設定をすることでスムーズに進めることができました。
また、デプロイの設定なども、社内の他プロジェクトの設定を見るだけでは分からない情報がたくさんありました。
しかし、詳しい人と一緒に構築することで1人で悩む時間を減らすことができました。
7. アプリケーションを開発している人との連携
インフラ構築と、アプリケーション側の設定を完璧に切り分けることはできません。
どちらが担当して設定をするのかを話すことが必要です。
これができておらず、アプリケーションのアラート設定をどちらがやるかが明確になっておらず、一時期放置されてしまっていたということがありました。
お互いが気づいたタイミングで確認して、設定し忘れることがないようにすることが必要です。
8. 多めに工数を見積もること
開発スケジュールにバッファを持たせることは重要です。
最初のうちは設定の抜け漏れや検討漏れは確実に出てくるので、予想よりも開発工数がかかってしまいます。
バッファを持たせることで、余裕を持って構築をすることができます。
まとめ
もう一度、それぞれのフェーズで重要だと感じたことをまとめます。
設計フェーズ
1. アプリケーションの特徴を把握すること
2. メリット・デメリットの両方を検討すること
3. 方向性がずれていないか、細かく確認すること
4. 社内のエキスパートには前々から情報共有をしておくこと
構築フェーズ
5. 手順書を作ること
6. 詳しい人と一緒に構築すること
7. アプリケーションを開発している人との連携
8. 開発スケジュールにバッファを持たせること
おわりに
この記事を読んで、スムーズにインフラ構築ができるようになればと思います。
明日のAteam Lifestyle x cyma Advent Calendar 2018の17日目は@water_resistantさんが 「GoogleChrome拡張にTensorFlow.jsを載せて笑顔体験」 という記事を書きます。
様々な技術を使っていつも面白いものを作っており、今回作ったものもとてもおもしろいので是非確認してみてください。
エイチームグループでは、一緒に働けるチャレンジ精神旺盛な仲間を募集しています。
興味を持たれた方はぜひエイチームグループ採用サイトを御覧ください。