自動化は、LogicMonitorの文化的DNAの一部です。 それが私たちの仕事の一部を自動化するのか、それとも自動化するのか ネットワーク監視 そのため、お客様はそれについて考える必要はありません。目標は常に進化しています。 私は、SaaSベースのLogicMonitorアプリケーションの可用性を処理するテクニカルオペレーションチームで働いています。 自分自身。 私たちは常に自動化の機会を探しています。 私たちの創造的な側面は、ヒューマンエラーの要因も取り除く独創的なソリューションを目指しています。 自動化を使用してスケーラビリティの問題を解決します。いくつかのリモート端末間でコマンドをコピーして貼り付ける時代は過ぎ去りました。 XNUMXつのWebサーバー？ ホスト名が頻繁に変わるので、XNUMXはどうでしょう。
XNUMX年近く前にLogicMonitorを始めたとき、 いくつかのプロジェクト モノリシックアプリケーションをサービス指向アーキテクチャに分解するために順調に進んでいました。 これは、より多くのサーバー、より多くのコンテナー、より多くの複雑さなどを意味しました。 この変化と相まって、絶え間ない成長がありました。 解決すべきより大きな問題はXNUMXつありました。ますます複雑化するインフラストラクチャをどのように管理し、すべての本番環境の同期を維持して、すべての顧客が一貫したエクスペリエンスを享受できるようにするかです。 そして、世界のどこですべてのアプリケーションが実行されていますか？ これらの問題に対処するには、新しいアプローチとツールが必要でした。
問題1：インフラストラクチャを持続可能な方法で拡張する
パブリッククラウドの使用を採用する典型的な理由から、アマゾンウェブサービス（AWS）を数年間使用してきました。 これらのリソースの作成を管理するために、さまざまな手作りのツールが開発されました。 あちこちに断片がありましたが、「インフラストラクチャテンプレート」を包括的に管理するものは何もありませんでした。 このアプローチでは、一貫性のない結果が生じました。 ドキュメントのRunbookを調べた後でも、環境を本番状態にするために必要なコマンド実行の欠落やAPI呼び出しが頻繁に発生しました（同僚の.bash_historyを覗き見しましたか？）。 合図 テラフォーム 救助へ。
HashiCorpのWebサイトから、「Terraformを使用すると、オペレーターは複数の場所で同じ構成を簡単に使用して、ミスを減らし、時間を節約できます」。 つまり、TerraformがEC2インスタンスやSQSキューなどのすべてのクラウドリソースを作成するために使用するコードスニペットを記述します。 コードはテンプレート形式で記述できるため、いくつかの変数を変更することで複数の環境を簡単に作成できます。 もうXNUMXつのHashiCorpツールであるPackerを使用してAmazonマシンイメージ（AMI）を構築するという前向きな経験があったので、Terraformを試してみました。 Terraformを最初に使用したのは、テスト/品質保証環境の作成でしたが、実験はうまくいきました。 リソースを削除する準備ができたら、Terraformはそれも処理できます。 チームのより多くのメンバーが参加し、Terraformはすぐにクラウドリソースを作成するための標準になりました。
Terraformを採用することの予期しない利点のXNUMXつは、作成するコードが、インフラストラクチャの構築方法のドキュメントとしても、既存のインフラストラクチャの説明としても機能することです。 これらの文書化されていないコマンドはすべてコードの一部になりました。 新しいインフラストラクチャを古いものと同じようにプロビジョニングし、途中で変更を加えても古いインフラストラクチャを最新の状態に保つことができました。
問題2：そのプロセスはどこで実行されていますか？
SOAモデルを採用することで、拡大し続ける複雑で動的なインフラストラクチャが推進されます。 Zookeeperなどのサービス調整ツールは、これらのタイプの環境で一般的に見られます。 動的なサービス検出を実行する方法が必要であることに気付きました。これにより、サービスが相互に通信する方法を認識し、オペレーターが特定のサービスが実行されている場所を特定できるようになります。 領事、HashiCorpの別のツールは、この要件などを満たしていました。 Consulを使用すると、独自のカスタムサービスチェック（特定のRESTエンドポイントへのGETリクエスト、期待されるリターンコードの照合、出力のキャプチャなど）を記述し、クエリを実行してヘルスステータスとサービスの実行場所の両方を判断できます。
サービスインベントリを提供することに加えて、自動化と信頼性を目的として、Consulとさらにいくつかの統合を行いました。 当社のソフトウェア展開では、Consulクエリを使用して、アップグレードが必要なアプリケーションとその実行場所を動的に決定します。 私たちのプロキシとロードバランサーは 領事テンプレート ルーティング構成ファイルを自動的に書き込みます。 これにより、人的エラーの可能性が少なくなり、より複雑なシステムを引き続き管理できるようにスケーラブルなモデルが提供されました。
これらは、最新のツールを使用してインフラストラクチャの増大する問題のいくつかを解決した方法の例です。 あなたが出席している場合 ハシコン 来週のオースティンでは、チームと一緒にこれらのトピックに関する質問に答えます。 ショーに参加しておらず、今後のLogicMonitor + Terraform統合についてもっと知りたいですか？ しばらくお待ちください–私たちはあなたのためだけのブログ投稿を持っています。
