河合 宜文 / Kawai Yoshifumi / @neuecc
Cysharp, Inc.
Cygames
C#大統一理論
C#
Slido
https://www.sli.do/
MicroBatchFramework
Cloud Native Batch Framework for C#
https://github.com/Cysharp/MicroBatchFramework/
2019年4月公開
・CLIツール作成のためのフレームワーク
・(クラウドネイティブな)バッチ作成のためのフレームワーク
> Install-Package MicroBatchFramework
.NET Generic Hostのうえに構築することでホスティングに関わ
ること(ロギング/DI/コンフィグ読み込み, etc...)をフルカバー
CLI Tools
.NET Core + CUI
.NET CoreによってC#でCUIツールを作成する価値の高まり
・ランタイム同梱(self-contained)の実行ファイル
・クロスコンパイル(Win/Linux/Mac)
・パッケージマネージャー(.NET Core Global Tools)
Parsing Commandline Argument
string[] argsをどう扱うか問題
標準では System.CommandLine が有力になりそう?(v0.2.0-alpha)
https://github.com/dotnet/command-line-api
パラメーターバインディング
public class Program : BatchBase
{
static async Task Main(string[] args)
{
await BatchHost.CreateDefaultBuilder().RunBatchEngineAsync<Program>(args);
}
public void Sum(int x, int y)
{
Console.WriteLine("Sum:" + (x + y));
}
}
.NET汎用ホスト
ASP.NETと共通の仕組みで
ホスティングを行う
class Program
{
static async Task Main(string[] args)
{
await BatchHost.CreateDefaultBuilder()
.ConfigureServices((hostContext, services) =>
{
services.Configure<MyConfig>(hostContext.Co
})
.RunBatchEngineAsync<MyFirstBatch>(args);
}
}
public class MyFirstBatch : BatchBase
{
IOptions<MyConfig> config;
ILogger<MyFirstBatch> logger;
public MyFirstBatch(IOptions<MyConfig> config, ILogger<
{
this.config = config;
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp2.1</TargetFramework>
<ToolCommandName>dotnet-ulid</ToolCommandName>
<PackAsTool>true</PackAsTool>
</PropertyGroup>
Cloud Natvie Batch
コンテナ化ビリティの高さ
PaaSやFaaSにどっぷり浸かること、ではないでしょう
オンプレミスまで含めたマルチクラウドなども当たり前のよう
に現れてる昨今(KNativeとかも)、唯一のポイントがコンテナ化
特定の何かに依存せず、コンテナ化していれば、この先どんな
風にでも戦っていけるし、いいんじゃないかという考え。
そしてC#なら.NET Core + LinuxでOK
// こんなクラスや
public class Foo : BatchBase
{
// こんなメソッドや
public void Echo(string msg)
{
this.Context.Logger.LogInformation(msg);
}
// こんなメソッドを
public void Sum(int x, int y)
{
this.Context.Logger.LogInformation($"{x + y}");
}
}
// こんなクラスを
public class Bar : BatchBase
{
public void Hello2()
{
this.Context.Logger.LogInformation("H E L L O");
}
}
Terminateシグナルなどのハンドリング
Ctrl + Cやdocker stopなどのイベントを
this.Context.CancellationToken でハンドリングできる
安全な終了(ログのフラッシュなど)に使えるほか
whileループでDaemonを作ったりも
Terminateシグナルなどのハンドリング
Ctrl + Cやdocker stopなどのイベントを
this.Context.CancellationToken でハンドリングできる
安全な終了(ログのフラッシュなど)に使えるほか
whileループでDaemonを作ったりも
public class Daemon : BatchBase
{
public async Task Run()
{
try
{
while (!Context.CancellationToken.IsCancellationRequested)
{
// do anything...
await Task.Delay(TimeSpan.FromMinutes(1), Context.CancellationToken);
}
}
}
}
CircleCI
コンテナをビルドするまでは、プラットフォーム中立にしたい
マルチクラウドが当たり前な昨今
(方言ばかりの)CIを各クラウド向けに書きたくない
CI定義は記述すれば使い回し/応用が効くので、
ある程度一つのものに集中してノウハウを固めたほうがプラス
CircleCIはかなりモダンなシステム、かつ日本でも流行している
CircleCI
コンテナをビルドするまでは、プラットフォーム中立にしたい
マルチクラウドが当たり前な昨今
(方言ばかりの)CIを各クラウド向けに書きたくない
CI定義は記述すれば使い回し/応用が効くので、
ある程度一つのものに集中してノウハウを固めたほうがプラス
CircleCIはかなりモダンなシステム、かつ日本でも流行している
version: 2.1
orbs:
aws-ecr: circleci/aws-ecr@3.1.0
workflows:
build-push:
jobs:
- aws-ecr/build_and_push_image:
repo: "microbatchsample"
Conclusion
アプリケーション開発者として
インフラの面倒は見ずアプリケーション開発に集中したい
SDK依存や実行環境依存なく自由に開発したい
FaaSは前者は満たすが後者は満たさない
後者を満たしながら前者も満たしてくれる世界が(私の)理想
そして(Kuberenetedを中心とした)コンテナエコシステムの進化
は、後者を満たしながら前者を満たす日も遠くなさそう
欠けたものを埋めて未来に備える
CLIツールのための周辺環境は揃ってるのに、どこか書きづらい
→MicroBatchFrameworkにより書きやすくなる!
いい具合のバッチ処理をまとめるものがない
→MicroBatchFrameworkによってあとはインフラの進化を待つだけ
C#を最先端のモダンな開発環境にする
まだまだ足りてないです!
自分で理想を見出して、一足先に埋めていこう
https://jp.surveymonkey.com/r/JBJKCJS

True Cloud Native Batch Workflow for .NET with MicroBatchFramework