紹介と弊社での運用事例についてご紹介しようと思います。進めるにあたってどういうツールを使っていますでしょうか。注目を集めているようですね。導入する前は下記のような悩みを感じていました。大量の設定をするときにポチポチ設定が面倒、時間がかかるインフラ構成変更の依頼フローが統一されていないこれらの悩みをツールの導入によって、解決したいなと考えていました。ついてCookpadのwinebarrelさんがメンテナンスされている、AWSをDSLの記述で管理できるツール群です。簡単に導入できるという点で、大変魅力的でした。どのツールも、簡単かつ直感的に使うことができ、生成されたコードも、Githubで管理できるので、上記のような問題も解決できると考えました。複数のツールを使っています。各AWSサービスを扱うのに必要なポリシー設定がされているアカウントがあれば、すぐにでも導入が可能です。例)RoadworkerRoadworkerはRoute53の管理を行うツールです。オプションを指定して、既存の環境設定をDSLとして出力できます。出力された、ファイルの中身は下記のようになっています。コマンドを使って、事前に適応内容を調べることができます。更新して、コマンドを実行すると下記のようなログが流れます。change冪等性が保証されているので、Route53がすでに定義ファイル通りの設定の場合は何も変更は行われません。統一されていて、基本的な操作の流れは変わらないので、非常に扱いやすいのも魅力です。一つのAWSアカウントで複数の運営サービスを管理されている場合や、運営サービス毎にAWSのアカウントを分けている場合があるかと思います。いずれにせよ、exportしたときのファイルが膨大になってしまうので、弊社では運営サービス毎にexportするディレクトリを分けて運用しています。ファイルを分割し、Routefile内で他のファイルをrequireする構成にしています。AWSアカウントやAWSサービス毎に毎回変更するのは面倒です。該当ディレクトリに移動すると、必要な環境変数が設定されるようにしています。中身は下記のようになっています。出してもらうフローで運用しています。ワークフローは下記のように行われます。本番環境に適応Elasticsearchなど複数のEC2インスタンスでクラスタを組んだりする際に、インスタンス全てに監視の設定をポチポチしていくのは大変な辛さがあったのですが、コードで管理しているので、既存の設定をコピーできて作業が大変楽になりました。変更内容の履歴が残るスタートアップではインフラ専門のエンジニアの確保はなかなか難しく、運用が属人化しやすいと感じています。履歴を追うことで分かるようになりました。用いて運用できるフローができたのは良かったと思っています。変更の適応もコマンドを実行するだけなので、オペミスを防止することができます。大量の設定をポチポチしながら変更していた運用も、既存コードのコピーで済ますことができ、開発効率が向上しました。導入で解決することができました。マージされたタイミングでの自動適応を行なって完全な自動化をしていきたいと思っています。部分的に代替となるツールの選定も進めていきたいなと思っています。さんをはじめとした開発者の皆様に心からお礼を申し上げます。二日目おはようございます。CTOを退任しました。(2)はてなブログをはじめよう!yutadayoさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。