この記事は弥生 Advent Calendar 2024の12日目の記事です。
こんにちは！弥生のサービスプラットフォーム部でエンジニアをしている寺山です。
中途で入社して約2年間、主に Azure 環境の運用保守に携わっています。
早速ですが、業務効率化や生産性向上を目指すにあたって「自動化」は欠かせないですよね！
今回は、Azure 環境で稼働しているサービスの運用効率化を目的に、自動化基盤をオンプレミスから Azure へ移行したお話をご紹介したいと思います。
はじめに
IT サービスを運用していくにあたって、多かれ少なかれ定型タスクが存在すると思います。
私が担当しているサービスにおいても、データ抽出用 DB コピー、運用メンバーのユーザー作成、一部カラムのマスキング、 KPI などのデータ抽出、オートスケール など、数多くの定型タスクが自動化されています。
当初、これらはオンプレミスの Windows Server 上でタスクスケジューラによって定期実行されていました。
しかしながら、このやり方にはいくつか問題があります。
①タスクが失敗しても気づけない
タスクスケジューラは設定したスケジュールに基づいてタスクを起動してくれますが、実行結果を監視する機能はありません。
別途仕組みを作り込む必要がありますが、そのようなことはしていませんでした。
そのため、あるタスクの失敗を検知することができず、他チームからの問い合わせで発覚して手動対応なんてこともたまにありました。
②実行元が止まるとタスクが実行されない
実行元である Windows Server はオンプレミスのメンテナンス用仮想マシンで冗長化も考慮されていません。
そのため、仮想マシンがダウンするとタスクが軒並み実行されないというリスクを常に抱えていました。
実際にダウンすることはありませんでしたが、もし起きた場合は１つずつ手動で実行するようなリカバリ対応が必要となります。（非常に面倒くさい、、）
③実行環境を自ら管理しないといけない
タスクスケジューラで定期実行しているスクリプトは主に PowerShell で記述されています。
例えば、複数の Azure リソースに対する操作を同時並行で実施する場合に Foreach-Object の Parallel パラメーターをよく使うのですが、こちらは PowerShell7.0 以降で利用可能となります。
また、 Azure を触っている方にはお馴染みの Az PowerShell モジュールも、バージョンによって使えるコマンドやコマンドの使い方が変わってくるので注意が必要です。
まだ他にもありそうですが、主に上記のような問題を解消するために実行基盤をオンプレミスからクラウドへ移行することを決めました。
弥生で使用しているクラウドサービスは AWS がマジョリティとなりつつありますが、連携面での高い親和性や権限管理のしやすさを考慮して Azure を採用しました。
採用した Azure サービス
実際に採用したクラウド基盤での自動化を助けてくれる心強い Azure サービスたちをご紹介します。
Azure Automation の Runbook
Azure Automation は、タスクをクラウド環境で自動化するための様々な機能を提供するオートメーションサービスです。
中でも一番使っているのは Runbook と呼ばれるスクリプト化された処理を自動実行する機能です。
任意のランタイムバージョンを選択して、 PowerShell や Python などでスクリプトを記述することができます。
また、PowerShell の場合、 Az PowerShell をはじめとする代表的なモジュールは既定で用意されています。
実行方法も幅広く用意されており、スケジュール実行やアクショングループからの実行、 Webhook を用いた外部からの実行も可能です。
さらに、Automation アカウント上で認証情報や変数を管理する機能があるため、重要な情報はコードと切り離すことでセキュリティを担保できます。
元のコードをコピペするだけ！とはいきませんでしたが、ほとんどのスクリプトを容易に移行することができました。
Azure Data Factory
Azure Data Factory は、Azure SQL Database、Azure Storage など様々なデータソースを取り扱う ETL サービスです。
移行対象のタスクには DB に対して SQL クエリを実行するものがあり、 Runbook への移植が少々面倒かつ処理が複雑化するものはこちらへ移行しました。
ノーコードで簡単に処理を作成できることに加え、Azure Key Vault を組み合わせることで接続情報や認証情報をセキュアに管理することができます。
また、パイプラインと呼ばれる処理単位は Runbook と同様にスケジュールやトリガー実行することも可能です。
Azure Logic Apps
Azure Logic Apps もノーコードでワークフローを作成して自動実行することができるサービスです。
こちらは、ビジネスプロセスを自動化できる RPA ツールとして Microsoft が提供する Power Automate と似ています。
構築済みの操作ブロックを GUI 上で自由に組み合わせることで思い思いのワークフローを作成することができます。
強みの一つとして、既述の Runbook や Data Factory のパイプラインを同一ワークフロー内で呼び出すことができ、「タスク A が成功したらタスク B を実行」といった順序関係があるタスクを簡単に実現することができました。
余談ですが、最近 GUI 周りが大きく改善されてかなり使いやすくなりました…！
結果
オンプレミスで抱えていた問題を概ね解消することができました。
①各タスクの実行結果を簡単に監視できる
今回採用したサービスはいずれも実行結果を Azure Monitor で監視することができます。
アラートを関係メンバーに対してメール通知するように構成しており、失敗をいち早く検知できるようになりました。
②クラウド基盤なので停止の心配がない
Microsoft が公開している SLA に基づいて、オンプレミスよりも高い可用性が保証されています。
万が一障害が発生したとしても、サービス正常性アラートで検知できるようにしています。
③実行環境の管理が楽
スクリプトの大半を移行した Runbook では、ランタイムバージョン以外の項目は意識する必要はありませんでした。
ランタイムバージョンもスクリプト作成時に選択するだけなので、ユーザー側で管理する必要はありません。
また、モジュールのバージョンも Azure Portal 上で管理することができ、更新も数クリックで完了します。
Azure Data Factory や Azure Logic Apps に至ってはそういった概念すらありません。
終わりに
今回は、自動化基盤をオンプレミスから Azure へ移行したお話をご紹介しました。
Azure の他サービスや AWS を含め、自動化や効率化を助けるサービスは数多く存在するため、色々試しながら継続的な改善を図っていきたいと思います。
もちろん、要件によってはオンプレミスを使わざるを得ないケースもあると思いますが、そうでないものはクラウドサービスへの移行を考えてみてはいかがでしょうか？
弥生では、一緒に働く仲間を募集しています。
herp.careers
