ついては紹介したことがあるので、今回は定期的なバッチ処理やジョブキューを介して非同期に実行されるようなオフラインの処理について、どのような環境を構築しているか紹介したいと思います。いうジョブ管理システムが稼動しており、複数のアプリケーションから利用されていました。定期的にジョブを実行するために必要な機能を十分そなえている一方で、複数のアプリケーション向けにワーカインスタンスをプロビジョニングする必要があること、ジョブを実行するワーカを柔軟に増減できないこと、といった欠点がありました。利用することにより、複数のアプリケーションから共通で使われつつもインスタンス側に必要なプロビジョニングを最低限に抑えることができるようになりました。インスタンス側の構成はシンプルになり、新しくアプリケーションを追加するときに必要な手間も非常に小さく済みます。キーやパスワードのような秘匿すべきクレデンシャルがインスタンスに直接置かれることを防ぎ、ワーカインスタンスのインスタンスプロファイルにすべてのアプリケーションに必要な権限をつける必要がなくなり、共通のインスタンスを複数のアプリケーションで使い回しつつも権限が適切に分離できるようになりました。利用するための機能追加やインスタンスの整備なども行いました。実行する環境も手に入るようになり、アプリケーション開発者にとってオフラインのジョブ実行をする際の障壁が大きく軽減されました。ようなコマンドを実行するようにしています。ような単発のコマンドを実行するために使います。ロールを利用できるようになったことがあります。利用したジョブを実行できるようになりました。いうジョブキューのしくみが整備されています。アプリケーションへのリクエスト起因であることが多いため、ジョブの実行回数、つまりジョブの実行に必要なリソースを事前に予想することが難しく、また時間帯によって刻々と変化するという特徴があります。したがって、常に安定的にジョブを実行しつつコストを抑えるためには、オートスケールが重要になってきます。導入によって、ワーカインスタンスのスケーリングが容易になりました。グループで管理するようにしました。引き上げ、再度実行を試みるようにしています。グループを指定することで有効化できます。メトリクスを定期的にチェックすることで行っています。保存しているため、直近の実績値を参照することで現在必要なリソース量を見積もることができます。下げることでスケールインを実現しています。スケールインするときには、実行中のタスクが中断されないように注意しなければなりません。されるまでの間に終了処理を行えるようになっています。経由でそのインスタンスに特別なタグをつけるようにしています。してサービスアウトし、その後ライフサイクルを継続させます。実行し続けるようにしています。利用しているとコンテナインスタンスのスケールアウトはしやすい一方で、スケールインをするには現状いくつかの工夫が必要になっています。使っている場合など、すべての場合で自動的にスケールインすることはまだできていません。このようなケースでもスケールインする方法を考える必要があります。スケールアウトをするタイミングが現状は実際にリソースが不足したときになっており、一時的にジョブの実行が遅れることになります。変えてからインスタンスが起動してコンテナインスタンスとして登録されるまで3分ほどかかっています。ジョブの実行ができるだけ遅れないようにするためには、インスタンスの起動を高速化する他に、リソースの使用状況の履歴から必要そうなときにあらかじめスケールアウトしておく方法があります。いう状況のときに実際にリソースが不足してスケールアウトしているかを観察し、その結果をもとにスケールアウトする基準をどうするかを決めようと考えています。オフラインのジョブで利用するメリットと、実際にどう利用しているかについて紹介しました。自体の改善を注視しつつ、アプリケーション実行環境の利便性を高めながらもできるだけコストを抑えられるように改善していきたいと思っています。機械学習チームの林田(@chie8842)です。技術部のヨシオリです。