THINKING MEGANE

論文執筆の道しるべ

論文執筆にあたり自分向けの指針のようなものがまとまってきたのでメモしておく。 以下の内容の一枚もののサマリがあると良いのではないか。

  1. 背景: なぜその課題に取り組むか
  2. リサーチクエスチョン: 何を解決したいのか
  3. 従来手法の整理: これまではその課題をどう解決していたのか、これまでのやり方に残った課題は何か
  4. 提案手法: 残った課題をどう解決したか
  5. 評価: 残った課題は定量的にどの程度解決したか

ここで

  • 2.のリサーチクエスチョンと3.従来手法の課題を混同しない。
  • 3.従来手法の課題、4.提案手法、5.評価はもれなく対応する。つまり、課題が3つであれば提案手法もそれらに対する解決アプローチを提示し、それぞれに評価が行われている。もしくは課題のうち、いくつを解決するものかを明示する。
  • これらは一枚まとめにすると良い。シーケンシャルな文章とこのまとめを交互に見直すことで道筋を外れずに具体と抽象を行き来できる(といいな)

上手な査読者のレビューは提案内容を除けば上記の観点での過不足を指摘しているように思える。 指摘事項に対する個別対処では、論文執筆力の向上はのぞめないのでこのような枠組みも意識して一定の水準での論文を執筆できるようにもなっていきたい。

また、議論から多くを得るためには

  • 分野のやや異なる人とは1.背景の説明を長めに取ることで自分の思い込みや暗黙の前提が浮き彫りにされ読み易い論文になる
  • 分野の同じ人とは同じ課題意識を持つとみなし、従来手法の整理と提案手法のアプローチを中心に議論する
  • 差読者目線を持つ人とは、リサーチクエスチョンを一言で伝わるか、それが解決したかをできるだけ手短に説明する

のような感じに使い分けると良いのではないかなと考えている。

コマンドラインオプションをパースするコードをコマンドラインオプションから生成するツールをつくった

コマンドラインオプションの形式は決まったけれども、パース処理を実装するために各言語やライブラリのドキュメントを読むことを繰り返していたので、この手間を省くためのツールをつくりました。

flagenは、先に決めたコマンドラインオプションから、これを解析するための各言語用のコードを出力するツールです。 オプション名から変数名や変数の型、デフォルト値が決定されるため、汎用的なボイラーテンプレートと比較して編集の手間が少なくなります。 また、テンプレートによって任意の出力を行えるため、エディタや自前のボイラーテンプレート出力ツールとの連携が容易です。 使いやすくするため、プリセットのテンプレートとしてGo、Ruby、Python、Shellのものを提供しています。

使い方

使い方は、テンプレートと実際に使う時のコマンドラインオプションを渡すだけです。

$ flagen YOUR_TEMPLATE YOUR_COMMAND_LINE_OPTIONS...

例えば、

$ flagen go --dist erlang -e k/l --lambda 1.5 -k 1 -v

と指定すると、Go用のコマンドラインオプションの解析処理を出力します。

var (
	dist	string
	e	string
	lambda	float64
	k	int
	v	bool
)

func init() {
	flag.StringVar(&dist, "dist", "erlang", "usage of dist")
	flag.StringVar(&e, "e", "k/l", "usage of e")
	flag.Float64Var(&lambda, "lambda", 1.5, "usage of lambda")
	flag.IntVar(&k, "k", 1, "usage of k")
	flag.BoolVar(&v, "v", false, "usage of v")
}

指定されたコマンドラインオプションから変数名、オプション名、型、デフォルト値が設定されることで編集の手間が極力ない状態になっています。

Python、Ruby、Shellの例はGodocのExamplesを参考にしてください。

テンプレート

テンプレートはGoのtext/templateを利用して解析されます。 テンプレート内では、.Flags(解析したオプションの情報)と.Args(残りのコマンドライン引数)が利用可能です。 .FlagsNameValueをもち、Valueは更にTypeGetをもちます。

以下は、解析したオプションの情報を列挙するシンプルなテンプレート(my.tmpl)です。

{{ range $flag := .Flags -}}
  {{ $flag.Name }}={{ $flag.Value.Get}}({{ $flag.Value.Type }})
{{ end }}
$ flagen my.tmpl --dist erlang -e k/l --lambda 1.5 -k 1 -v

このテンプレートから以下の出力を得ることができます

dist=erlang(string)
e=k/l(string)
lambda=1.5(float)
k=1(int)
v=false(bool)

また、テンプレート内では文字列のケース変換のための関数を利用することができます。 主に変数を言語の命名規約に合わせるのに使えます。 使える関数は、こちら で確認ください。

連携

Vim

flagenの結果は標準出力を使っているため、エディタとの連携も容易です。 例えば、Vimでは以下により、カーソル位置に結果を挿入することができます。

:r!flagen YOUR_TEMPLATE YOUR_COMMAND_LINE_OPTIONS...

ボイラーテンプレート出力ツール

flagenはライブラリとして利用することができるため、自前のボイラーテンプレート出力ツールがGo製であれば以下のように呼び出すことができます。

	tmpl, err := flagen.NewTemplate(args[0])
	if err != nil {
		return err
	}
	return tmpl.Execute(outStream, args[1:])

また、独自の関数が必要な場合は flagen.TemplateFuncMapに設定することでテンプレート内で利用することができます。

ワークアラウンド

曖昧なフラグ

flagenはオプションに値が指定されていないときにboolだと見なすため、以下のようにboolフラグで終わって引数がある場合に判断がつきません。

$ flagen TEMPLATE --bool-flag arg1

想定どおりにするためには値としてtrue or falseを受け取ることを明示する必要があります。

$ flagen TEMPLATE --bool-flag=false arg1

まとめ

様々な実装が提供されているコマンドラインオプションの解析処理を利用形式から動的に生成するジェネレーターとしてflagenをつくりました。実際にいくつかの言語のテンプレートを用意してエディタと連携させることでCLI開発の効率が改善しています。

今後はflagen自体のオプションとしてprefixなどを提供すれば構造体の変数に設定する用途などのテンプレートとの相性もよくなりそうだと考えています。 便利なテンプレート追加のプルリクエストやイシュー、ボイラーテンプレートのツールへ組み込んだ報告などお待ちしています。

Fukuoka.go

このツールはFukuoka.go#14+Umeda.goで発表しました。 発表資料はこちらです。

待ち行列理論に使われる分布に従う乱数をGo言語で生成する

待ち行列理論をシミュレーションする際にいくつかの分布に従う乱数を生成する必要があったのでメモ. また,確率まわりの用語と分布についても理解が曖昧な点があったのでこの機会にまとめておく.

用語の整理

確率

確率は,

\[ \frac{ある事象の起こる場合の数}{全ての事象の起こる場合の数} \]

で求められる.

確率変数

確率変数は,事象に対応した実数のこと. 確率変数には,離散型と連続型の二種類がある. サイコロの出目のようなものは離散型で,身長や体重のような(原理的には)連続の値になるものは連続型.

確率分布

確率分布は確率と確率変数との対応付け. そもそも辞書的な意味での「分布」は「粗密の程度を含めた,空間的な広がり具合」を表す. 度数分布では階級と度数(階級に含まれる変量の数)の対応付けであった. また,これらの分布は,度数分布と同様に確率分布表や確率分布グラフとして表すことができる.

確率を返す関数

ここで,ある確率変数を入力に,対応する確率を出力する関数を考える.

確率質量関数

離散型の確率変数であれば,確率分布表を照会し,対応する確率を得ることができる. 確率変数を入力に,対応する確率を出力する関数を確率質量関数(または確率関数)[1]と言い,サイコロの出目を確率変数$X$とした時に1が出る確率を$P(X=1)=\frac{1}{6}$のように書ける. もちろん確率の総和は1である.

確率密度関数

連続型の確率変数の場合は,ある一点の値を入力とすると対応する確率は常に0となる. これは,ある範囲においても実数は無限個あるため,全事象が無限になることから,確率の定義より$\frac{1}{\infty}=0$となるためである. このように連続型の確率変数からは直接的に確率を求めることができないので,この連続型の確率変数を対応する「何か」に変換する必要がある. また,その「何か」は確率に変換できる必要がある. 確率の定義から,総和は1である. また,連続型の確率変数であることから,和は積分で求めることになる.

連続型の確率変数をx軸に,この連続型の確率変数を対応する「何か」をy軸にプロットした時に,ある範囲の割合は該当範囲の定積分によって導くことができる. そして,全体の積分が1で,その中のある範囲の定積分が,事象がその範囲に含まれる確率に従うような「何か」があれば,それを連続型の確率変数の確率に用いることができる. そのような「何か」が存在するとき,「何か」は「確率密度」と呼ばれ,連続型の確率変数を入力とし,確率密度を出力する関数を「確率密度関数」と呼ばれる[2].

このとき,確率密度関数$f(x)$に従う確率変数$X$が$(a \leqq X \leqq b)$となる確率は\[\int_a^b f(x) dx\]のように書ける.

確率密度は,その確率変数の相対的な発生のしやすさを表すに過ぎないので,部分的にy軸(確率密度関数の返す値)が1を超えても構わない(全体の面積として1になれば良い.例えば,確率密度関数が$f(x)=2x (0 \leqq X \leqq 1)$のときなど).

待ち行列理論で使う分布

待ち行列理論では待ち行列のモデルの構造を以下のようなケンドール記号を用いて記述する.

  • X/Y/S(N)

ここでXは到着過程の種類,Yはサービス過程の種類,Sは窓口数,Nは待ち行列の長さの制限数が入る. 過程の種類は以下の通り.

種類説明備考
Mマルコフ過程到着過程ならポアソン分布,サービス過程なら指数分布
D確定分布到着間隔やサービス時間が一定
G一般の分布平均値と分散が既知の任意の分布
$E_k$アーラン分布k個の指数分布の和の分布

ポアソン分布

単位時間に平均$\lambda$回起きる事象が単位時間に$k$回発生する分布[3].

平均が$\lambda$のポアソン分布を表す確率質量関数は\[P(X=k)=\frac{\lambda^{k}}{k!}\cdot e^{-\lambda}\]であり平均$E[X]$は$\lambda$となる.

指数分布

平均$\theta$時間に一回発生する事象の発生間隔を表す分布[4].

平均が$\theta$の指数分布を表す確率密度関数は\[f(x)=\frac{1}{\theta}e^{-\frac{x}{\theta}} (x \geqq 0)\]であり平均$E[X]$は$\theta$となる.

待ち行列とマルコフ過程

あるランダムに起きる事象を発生回数から見たのがポアソン分布,発生間隔(または時間)から見たのが指数関数とみなすことができる. マルコフ過程は未来の挙動は過去の挙動とは無関係であるとする性質を持つ確率過程であり,これらの分布が適合するため利用されている.

単位時間に$\lambda$回到着するとした到着過程はポアソン分布が利用されるが,シミュレーションにおいては平均到着間隔を知りたい. この場合は,$\frac{1}{\lambda}$を到着間隔とした指数分布で求めることができる(1時間に平均5人くる場合,平均1/5時間(12分)の間隔で到着する). つまり,$\theta=\frac{1}{\lambda}$として,確率密度関数は\[f(x)=\lambda e^{-\lambda x} (x \geqq 0)\]であり平均$E[X]$は$\frac{1}{\lambda}$となる.

なお,ポアソン分布と指数分布の関係の理解には[5]が参考になる.このサイトでは時刻$t$を導入したポアソン分布の累積分布関数から指数分布の確率密度関数を導いている.

アーラン分布

まず,ガンマ分布は平均$\theta$時間に一回発生する事象(指数分布)が$k$回発生するまでの時間の分布[6]である. ガンマ分布の$k=1$のとき,指数分布と等しく,$k$が整数の場合にアーラン分布と呼ばれる.

ガンマ分布を表す確率密度関数は\[\frac{1}{\Gamma(k)\theta^{k}}x^{k-1}e^{-x/\theta}\]であり平均$E[x]$は$k\theta$となる.

また,前述のポアソン分布のパラメタから指数分布の確率密度関数を求めたのと同様に,$\theta=\frac{1}{\lambda}$として,確率密度関数は\[\frac{\lambda^k}{\Gamma(k)}x^{k-1}e^{-\lambda x}\]であり平均$E[x]$は$\frac{k}{\lambda}$とも書ける.

ここまで,$k$回の$\theta=1/\lambda$の指数分布を場合を見てきたが,待ち行列理論の書籍においては,$k$回の$\frac{\theta}{k}=\frac{1}{k\lambda}$の指数分布としている場合がある. すなわち,一つのサービス時間$\theta$が$k$個の工程(1工程あたり$\frac{\theta}{k}$)からなるとみなしている. この場合,確率密度関数は\[\frac{(k\lambda)^k}{\Gamma(k)}x^{k-1}e^{-k\lambda x}\]であり平均$E[X]$は$\theta=1/\lambda$となる.

待ち行列理論で使う分布に従う乱数

ここでは,ある分布に従う乱数をGoでの生成する.

指数分布

指数分布に従う乱数はGoの標準パッケージmath/randで提供されている.

func Exponential(rnd *rand.Rand, lambda float64) float64 {
        return rnd.ExpFloat64() / lambda
}

パラメタ$\theta=1/\lambda$に合わせるためには結果を$\lambda$で割る(平均到着率が増えるほど平均到着間隔は狭くなる).

動作確認のため,生成した乱数のヒストグラムと指数分布の確率密度関数を重ねてプロットした.

hist_and_pdf_exponential

ポアソン分布

ポアソン分布に従う乱数はGoの標準パッケージで提供されていない. そこで指数分布とポアソン分布の関係性を利用して,指数分布で得られた乱数の和が1を超えるまでの最小のカウント数を用いる方法がある[7][8]. 例えば平均到着率($\lambda$)が5人であれば,平均到着間隔($1/\lambda=0.2$)である. ここでカウントは$0.2*5$が平均して得られると考えられる.

func Poisson(rnd *rand.Rand, lambda float64) float64 {
        p := 0.0
        for i := 0; ; i++ {
                p += Exponential(rnd, lambda)
                if p >= 1.0 {
                        return float64(i)
                }
        }
        return 0.0
}

生成した乱数のヒストグラムとポアソン分布の確率質量関数のプロット.

hist_and_pmf_poisson

アーラン分布

アーラン分布もしくはガンマ分布に従う乱数はGoの標準パッケージで提供されていない. しかし,ガンマ分布の定義(k個の指数分布の和の分布)[6]から以下の実装が可能である.

func ErlangKL(rnd *rand.Rand, lambda float64, k int) float64 {
        g := 0.0
        for i := 0; i < k; i++ {
                g += Exponential(rnd, lambda)
        }
        return g
}

ここで,KLは平均が$\frac{k}{\lambda}$であることを表している.

生成した乱数のヒストグラムとアーラン分布の確率密度関数のプロット.

hist_and_pdf_erlangkl

待ち行列理論の参考書にあるようなサービス工程を$k$個に分割するアーラン分布では$k$回の$\frac{\theta}{k}=\frac{1}{k\lambda}$の指数分布となることから以下の実装となる.

func Erlang1L(rnd *rand.Rand, lambda float64, k int) float64 {
        g := 0.0
        for i := 0; i < k; i++ {
                g += Exponential(rnd, float64(k)*lambda)
        }
        return g
}

ここで1Lは平均が$\frac{1}{\lambda}$であることを表している.

生成した乱数のヒストグラムとアーラン分布の確率密度関数のプロット.

hist_and_pdf_erlang1l

動作確認用のコード

動作確認用のコードは以下にある.

このような感じで利用できる.

go run main.go -size 100000 -dist erlang -e k/l -lambda 0.5 -k 2 > data.txt && python plot.py --dist erlang -e k/l --lambda 0.5 -k 2

参考

Kaburaya AutoScaler: 多環境での運用性を考慮した自律適応型オートスケーリング制御系

このエントリは、第五回 Web System Architecture 研究会 (WSA研)の予稿です。

はじめに

Webサービスの運用において,急激なアクセス頻度の上昇に対する安定性を保つため,Webアプリケーションにスケーラビリティの仕組みが一般的に求められるようになった. これを支援するためにWebアプリケーションを稼働させるクラウドサービスやオーケストレーションツールから,オートスケーリング機能が提供されている. これらのオートスケーリング機能では,開発運用者が予め定めた条件を元にWebアプリケーションの状況が監視される. そうして,条件を満たせば,開発運用者が予め定めたスケール方法とその実施量に従いWebアプリケーションをスケールさせる.

このようにオートスケーリングによって,ユーザからのリクエスト数の増減に応じて最適なサーバ台数を調整されることで利用者の快適さと情報システムの運用コストを両立できるようになった. 一方で,オートスケーリングを導入し,継続的に安定した運用するためには開発運用者の運用努力が必要であるが,これらは管理する環境の増加に従い困難になる. そのため,多環境での運用性を考慮した自動化可能なオートスケーリング戦略が求められる.

オートスケーリングの継続的に安定した運用に向けた課題は大きく二つある. 一つ目は,アプリケーション特性の把握,二つ目は,“遅れ”の考慮である.

課題1: アプリケーション特性の把握

スケールにはWebアプリケーションを稼働する仮想サーバへリソースを追加する垂直スケール(スケールアップ),稼働する仮想サーバを追加する水平スケール(スケールアウト)の2種類の方法がある. しかしながら,どちらの方法を用いるにせよ,開発運用者はWebアプリケーションの特性に応じたオートスケーリングの条件やその実施量を予め定める必要がある. 例えば,時刻ベースであればアクセス頻度の時系列的傾向や,リソース変動ベースであればボトルネックとなるメトリクスである. また,これらの条件に対する必要台数の算出も必要となる. Webアプリケーションは常に変更が加わることから,手動での継続的な特性の把握と決定は運用負荷の面で現実的ではない.

そこで,特性把握の自動化が行われている. 三宅らは,過去のアクセス頻度のデータからLSTMを用いて24時間先までの1時間単位のアクセス頻度を予測するモデルを構築し,予測アクセス頻度を元に経験から得られたサーバ単位のスループットにより必要なサーバ台数を求めた[1]. スループットの把握では,パラメタを連続的に変化させながら最良の結果を得る値を探索的に求める方法も提案されている[2]. これらの予測的,探索的なアプローチによる特性把握の自動化により,変化する環境に対する追従性は向上する. 一方で,事前的なアプローチであるため,予測の誤差,探索を行った環境と本番環境の誤差に対処できないという課題が残る.

そのため,三宅らはフィードバック制御による個別の特性把握を必要としないアプローチ[3][4]を提案した. この手法では,直近のレスポンスタイムが均衡する点に収束するような台数調整によって特性把握が不要で実行時に誤差を修正することができる. ただし,フィードバック制御を用いるため,制御量であるサーバ台数の決定は探索的である. 待ち行列理論によれば窓口利用率が1を超えると待ち行列は収束しないとされていることから,サーバ台数は即時かつ決定的に求められることが望ましい.

課題2: “遅れ”の考慮

オートスケーリングでは,本番環境の誤差に対応するための即応的なアプローチを採用すると”遅れ”の課題が発生する. 一つ目の遅れは,負荷上昇からサーバ台数を見積もるまでの時間差である. 本稿ではこれを「入力の遅れ」と呼ぶ. 次はサーバ台数の変更指示から起動までの時間差である. 本稿ではこれを「出力の遅れ」と呼ぶ. 待ち行列理論によれば窓口利用率が1を超えると待ち行列は収束しないとされていることから,これらの遅れに対して発生した待ちリクエストが系の安定性を崩す. 安定性の低下は開発運用者による不定期な対応を要請し,運用負荷につながることからこれを回避する必要がある.

そのために,遅れを最小化する手法が適用される. 入力の遅れでは,変化点検出などにより負荷上昇を即時に察知する方式がある. また,出力の遅れではCRIUを利用することで起動までの時間を短縮する方式[5]がある. しかしながら,精度の観点やシステム制約によって遅れを0にはできないため,遅れそのものに対する対策は必要となる.

遅れを踏まえた準備では,前述の予測的なアプローチが考えられる. 三宅らの手法[1]では,予測と事前起動によりこれらの遅れを考慮するが,本番環境の誤差への課題が残る. そこで,スミスの予測法[6]のようにフィードバック制御において遅れによる影響を踏まえた制御量を算出する手法がある. 一方で,予測のためには精度の高い予測モデルの構築が必要であり,追従にはここの自動化が必須となる.

提案手法

多環境での運用性を考慮したアプリケーション特性の把握の自動化と安定性の両立のためには,以下の要件が必要となる.

  1. Webアプリケーション特性として負荷に対する実施量の関係が把握できる
  2. これを不必要な負荷をかけることなく実行時に自動で把握できる
  3. 把握したWebアプリケーション特性と実環境に誤差が生じた場合に修正できる
  4. これを実現するリアクティブなアプローチで発生する”遅れ”へ対処できる

そこで,フィードフォワード制御を中心とし,実環境の特性把握・追従のためにフィードバック制御を組み込んだ2自由度のオートスケーリング制御系を提案する. 提案手法により,特性把握・追従の自動化ならびに待ち行列理論を用いた決定的な台数算出・遅れ補償による安定化が見込める. なお,本提案手法の実装はKaburaya AutoScalerとして,OSSでの公開・開発を続けている.

提案手法では,Webアプリケーション特性を求めるにあたって低負荷時では理想的なレスポンスタイム,高負荷時ではスループット限界を用いることで対象のWebアプリケーションに不必要な負荷をかけることなく現状に即したWebアプリケーション特性を把握することができる. また,仮想サーバ起動までの遅れに伴う負荷状況を予測し,これを見越した実施量を見積もる遅れ補償機構を設けた.

提案手法のアーキテクチャを以下に示す.

Kaburaya AutoScaler Architecture

ここで$F$はフィードフォワード制御部である. 現状の負荷状況に応じて実施量であるサーバ台数を算出する. 算出には待ち行列理論の窓口利用率を求める式を変形した$\lambda/\rho\mu$を用いる. なお,$\lambda$は平均到着率(req/単位時間),$\mu$は平均サービス率(req/単位時間),$\rho$は窓口利用率を表す. 提案手法では$\rho$には0より大きく1未満の任意の値を設定することができる.

$P$はプラントであり,$F$で求めたサーバ台数を用いて実際にWebサービスを運用する実環境である. 提案手法では実環境の計測誤差をフィードバックすることで自動かつ継続的な安定性を保つ. $P$は計測結果として単位時間での平均レスポンスタイムである$T_s$と単位時間での1台あたりの処理数である$\mu$を返却する. これらの値は,$F$における新しい$\mu$に用いられる.

提案手法では仮想サーバ起動までの遅れに伴う負荷状況を予測し,これを見越した実施量を見積もる遅れ補償機構を設けた. 待ち行列理論では無限時間の平均した待ち時間を求めるため,窓口利用率が1以上の場合に発散し,理論を適用することができない. 一方で,遅れ時間は有限であることから,窓口利用率が1以上の場合であっても待ち行列の長さを求めることができると考えた. そこで$(\lambda^{t-1}-s^{t-1}\mu^{t-1})\gamma$のように不足処理能力による待ち行列の長さとて加えて,これを捌くことができるサーバ台数を求めている.

評価

プラントのシミュレータを使って提案手法によるオートスケーリングの自律・適応の性能を評価した.

Evaluation

右下のグラフにより$\mu$の推定・追従が行えていること,左上のグラフにより遅れ補償が働きアクセス増加時に一時的に多いサーバを投入することで収束できていることが確認できる. 個別の評価についてはスライドを参照されたい.

発表スライド

まとめ

本研究会ではオートスケーリングと開発運用者間の関係をなめらかにするための多環境での運用を考慮した自律適応型オートスケーリング制御系を提案した. 評価ではM/M/Sモデルを前提としたプラントシミュレータによってこれらが達成可能なことを示した. 実用化に向けて今後はプラントに実際のWebサーバ/アプリケーションサーバを適用した評価や実際の到着,サービス時間間隔に近い分布での評価が必要である. また,提案手法では入力の遅れに伴い単位時間内に待ちリクエストが必ず発生するため変化点検出などで遅れ時間自体を短縮する方式も検討したい.

発表を終えて

今回のWSA研究会もとても面白かった. Webシステムアーキテクチャという題材で色々な分野の人が集まって議論することで持ち寄ったアイディアが前進して行くのを何度も見ている. 自分自身の取り組みも研究としてWSA#3からWSA#4を通してGopherConで登壇できるぐらいに育った. 加えて,今回は,オートスケーリングの課題に着目して新しいアプローチを試してみる中で,制御工学や待ち行列理論などを学び楽しめた. このような普段の研究から少し離れた取り組みであっても,定期的に発表を促されることで形にすることができるのはとても大切で,やりっぱなし学びっぱなしではなく一つの区切りまで考え実装することで次回以降の研究への糧となる. Webシステムアーキテクチャに関する運用知見を研究的アプローチで前進させること興味がある方は次回開催の参加を検討してみてはいかがでしょうか.

リファレンス

  • [1]: 三宅 悠介, 松本 亮介, 力武 健次, 栗林 健太郎, アクセス頻度予測に基づく仮想サーバの計画的オートスケーリング, FIT 2018 第17回情報科学技術フォーラム, CL-002, Sep 2018.
  • [2]: 全自動パラメータチューニングさん https://blog.mirakui.com/entry/2013/02/20/003401
  • [3]: Yusuke Miyake, Optimization for Number of goroutines Using Feedback Control, GopherCon Marriott Marquis San Diego Marina, California, July 2019.
  • [4]: 三宅 悠介, Ebira: アクセス負荷に応じて継続的にスケーリング基準を最適化する汎用オートスケーリング機構, 第四回 Webシステムアーキテクチャ研究会, 2019年4月.
  • [5]: 松本 亮介, 近藤 宇智朗, CRIUを利用したHTTPリクエスト単位でコンテナを再配置できる低コストで高速なスケジューリング手法, 研究報告インターネットと運用技術(IOT), Vol.2019-IOT-44, pp.1-8, Feb 2019.
  • [6]: O. Smith, “Closer control of loops with dead time”, Chemical engineering progress, Vol. 53, No. 5, pp. 217-219, 1957.

初めて海外カンファレンス登壇するためにやったこと

7/24から27にかけてアメリカ、サンディエゴで開催されたGopherCon 2019で人生初となる海外カンファレンスに登壇してきました(発表の様子はこちらにまとめました)。 GopherConはGo関連で最大級の国際カンファレンスです。 6年目となる今年は世界中から1,800名のGopherが参加し、200名以上の応募の中から選ばれた36名がスピーカーとして登壇しました。 その中で、僕は「Optimization for Number of goroutines Using Feedback Control」というタイトルで45分のチュートリアルセッションを務めました。

これまで海外カンファレンス登壇経験はなく、英語にも不慣れであるものの、現在の自分にとって非常に重要な位置付けのイベントであり、1月のCfPから7月の発表に至るまでの長丁場を非常に高い優先度で取り組んできました。 これらの取り組みについて、自分自身の次の登壇への振り返りとして、何より今後、僕と同じように海外カンファレンス登壇を目指す方にとって何かしら参考になればと思いまとめておきます。

採択に向けて

投稿のネタを育てておく

まずは話すネタがなければ投稿できません。 普段の業務やOSS活動で得た生の経験や実績は、頭の中にあるだけではやがて自分にとって当たり前になり輝きを失っていきます。 そのため、普段から忘れないように登壇ネタとしてメモしておくだけでも有効です。 ただ、実際には、ブログや国内の勉強会での登壇などを通して、カタチを与えて上げておくと良いと思います。 このアウトプット作業に暗黙的に含まれる他人に伝えるという制約によって、ただの経験が洗練されてよそゆきの顔になっていくからです。 つまり、曖昧だったり複雑な部分を解きほぐし自分の理解が深まることで提案や動機付けに対する説得力が生まれます。

今回の僕のネタは、幸いにもこの機会に恵まれました。 関連研究も含めるとWSA研究会とGoCon東京の計3回の発表とフィードバックを通して(現在進行形で)育てています。

投稿のネタを選ぶ

どのようなネタであってもぜひ挑戦させてあげてください。 採択される可能性が限りなく高いネタはあっても絶対に通るネタはないのではないかなと思います。 なぜならカンファレンスの特徴や査読者のバックグラウンド、他の発表とのバランスなど採択には色々なパラメタも影響するからです。 なので、僕は@tenntennさんのこのスタンスで良いと思います。

提出することで査読者からのフィードバックがもらえることもありますし、カンファレンス登壇に興味があればまずは応募してみましょう…!

ただし、発表実現性が著しく低いものは避けましょう。 発表までに実装や評価は間に合いますか?(採択されたら当日までにやることは他にもたくさんあります) プロポーザルを書くコスト、査読するコストは発表実現性が高いものへ。

プロポーザルの書き方を学ぶ

いかにして提案を査読者にアピールするかは重要であり難しい取り組みです。 ただし、査読者が求める事項は一般に共通しており、それゆえにベストプラクティスはあります。 今回、僕は@tenntennさんから教えてもらった以下のサイトに目を通してプロポーザル執筆に臨みました。

もちろん対象のカンファレンスの選考基準も目を通します。

The selection criteria:

  1. Relevance. The talk is relevant to the Go community. GopherCon is not a general software conference, our audience wants to hear about topics that relate to the Go programming language.
  2. Clarity. You’ve clearly explained what you are going to talk about.
  3. Correctness. You’ve demonstrated knowledge of your topic. You don’t have to be an expert, but you are expected to be speaking from experience.
  4. Achievability. You’ve thought about how to present your material in the time available.
  5. Impact. The goal of the talk. What new idea, technique, tool, or information will the audience leave your presentation with?

僕はこの辺の書き方は論文執筆と同じだなあという感想を持ちました。 つまり、提案の新規性、有用性、信頼性などをわかりやすい構成で伝える技術です。 一方で、上で引用したGopherConの選考基準では、「専門家である必要はないが経験から語ることが期待される」と言う文言がありました。 これは一般論で終わらないことを伝えていると捉えられますが、やったことをそのまま出せばいいというわけでもないはずです。 つまり、経験から得られたものを一般化したり、潜在的な課題へと結びつけて、より多くの人に何かを持ち帰ってもらえるように思考することが求められます。 そういう意味ではやはり論文執筆に通じるものを感じます。

ただ、先の選考基準は「自分で」敷居を上げすぎるなという側面もあるとは思っていて、まずやったことを書く、それから上記を意識しながら少しづつ改善していくことが大切なのだろうと思います。

プロポーザルを書く

プロポーザルの書き方に従い、選んだネタを使ってプロポーザルを書きます。 英語に慣れていない場合はまず日本語で書くと良いと思います。 問題をわかりやすく整理して、可読性の高い構成にするのは難しい仕事なので、日本語で作って英語にする方が結果的に時間的・品質的に満足できるからです。

提案型の場合、汎用的には以下のような流れで文字数制限に応じて分量を調整していけると思います。

  • 1. 現状(現状における問題の定義。つまり理想状態との差)
  • 2. 背景(定義した問題に対する従来のアプローチの整理。それらのアプローチの持つ課題を”自分なりに”整理)
  • 3. 提案(その課題を解決する方法を提案)
  • 4. 評価(提案手法の有効性を評価する方法、あれば結果を含める)

従来ツールによる解決であれば、3はそのツールの紹介に、4は導入事例になります。 いずれにせよ、このようにしておくと各ステップの検討事項が分離できるので順番に議論すれば後戻りが発生しません。 つまり査読者の思考の流れを妨げません。 理想状態を念頭に、解決したい本当の問題と、従来アプローチの制約事項をうまく分離してあげるように考えるのがコツでしょうか。 これは難しいので投稿ネタを育てる工程で意識しながら繰り返しやっておくと良いと思います。 なお、論文だと理想状態がなぜ理想なのかの説明も求められるので大変ですが、エンジニア系のカンファレンスだとコンテキストが共有できているのでそこに文字数を割かなくても大丈夫です。 また、エレベータピッチなどの極端に文字数が少ない場合は、1の理想と2の整理した課題だけを述べて3に繋げています(4は含めない)

参考までに、僕が今回提出したプロポーザルを下記に置いておきます。 タイムテーブルのセクションは@tenntennさんの以前のプロポーザルを参考にさせてもらいました。 査読者目線からも、提案の整合性や発表内容に対する時間配分の妥当性などが分かるのでとても良いセクションだと思います。

プロポーザルを英語化する

まず、Google翻訳に放り込みたくなる気持ちをぐっと我慢します。 Google翻訳の進歩は目覚ましいですが、元となる日本語の文章に曖昧な点があるとどうしても翻訳の精度は下がります。 また、係り受けの複雑な日本語の文章も、いたずらに長い文章へ翻訳され、文字数あたりの情報量が減ることもあるでしょう。 査読者の思考を妨げないためには、簡潔で明解な英語文章が必要です。 そのためには、元の日本語の文章を以下の点でチェックすると良さそうです。

  • 主語・述語があるか
  • 主語・述語がねじれていないか
  • 事実か意見かが判断できるか
  • 係り受けが適切か(不要な修飾を減らす、修飾順番を整理)
  • 文章が複数の主張を含んでいないか(文の分割を検討)
  • 接続助詞(〜が、〜て、〜ので)は従属節との関係を曖昧にしていないか(厳密な接続助詞への変更か文を分割)

校正後の日本語文章に対しては、比較的短く基本的な構文だけで英作文ができるはずです。 なお、専門用語や言い回しについては、普段から興味のある分野で論文や技術書を英語のものを読んで、レパートリーを増やしておくと良いです(自戒を込めて)。

ギリギリの提出を避ける

提出時期は早ければ早いほど良いでしょう。 今回、締め切りの5日前に提出しましたが、アーリーフィードバックとして、セッション枠の変更(25分ではなく45分へ)をはじめとする幾つかの提案をもらいました。 これが締め切り寸前だと、もらえなかったかもしれず、そうすると時間に対するコンテンツ過剰によって発表の実現性が低く採点され、採択されなかった可能性もあります。

実際、投稿数の遷移について、締め切り3日前が87、前日で130、当日の中間発表で192のように駆け込みで投稿数が一気に増える様が伝えられています。 査読者数も限界があるため、締め切り前の全員分にアーリーフィードバックを返せないとすると、提出は早いほうがオススメです。

僕がもらったフィードバックはこのようなものでした。

I have some early feedback from the reviewers. The general feeling is this is too much content to cover in a 25 minute keynote slot and may not be generally applicable to the full audience. The recommendation from the reviewers is to revise this proposal as a 45 minute tutorial session

You can edit your proposal at any time before the end of the month. Best of luck!

英語学習

英語によるコミュニケーションは普段からの積み重ねが全てです(はい…)。 この章に関しては誇れるものではないので参考までにお読みください。

僕の場合、発作的に英語をやって身につかずに終わるというのを長年繰り返していました。 そこで、今回、PROGRITという英語コーチングサービスを使ってカリキュラムを組んでもらい継続的な学習をサポートしてもらうことにしました。 結構なお値段(いやほんと)します。 カリキュラムも画期的な手法というよりは地道にやることで効果が見込める王道のものを組み合わせていて、これを如何に継続してやり抜くかをサポートすることがサービスのコアかなと感じます。 なので、自分にあった勉強法を見つけて継続してやれている方にとってはあまり意味のないサービスかもしれません。 とはいえ、前述の英語に対する僕のニーズにはあっていたので今回利用しました。 結果的に、Versantという英語コミュニケーション能力を図るテストは3ヶ月のカリキュラムを終えて5点上がり(TOEICだと75点UPぐらい?)、やはり継続は力だなと感じています。

カリキュラム

最終的に日々のカリキュラムは以下のように落ち着きました。

  • 瞬間英作文(60min)
  • 単語(30min)
  • シャドーイング(45min)
  • 多読(45min)

登壇と質疑応答、そしてスピーカーディナーで自分の考えを述べられることを目標に進めました。 英文法についてはなんとか理解しているものの、それらを「使う」ことの準備がほぼできていないことが分かったため、そこを補強するカリキュラムとなっています。 つまり、英語を使ったコミュニケーションに必要な、文章や単語を通した概念と音声の変換に関する、知覚と瞬発力を鍛えます。

まず単語は何をやるにも基礎となるのでひたすらボキャブラリを増やします。 僕はキクタンを使って自分のレベルにあったものから進めました。 一方で、発表に向けては普段から興味のある分野で論文や技術書を英語のものを読んで、ボキャブラリを増やしておくと良いのだろうなとも思いました。

次に、概念と文章をつなぐ瞬発力向上のために、瞬間英作文をやりました。 機械的に翻訳するような平易なものを瞬間で解くのはパズルのようで面白いですが、繰り返すと飽きてくるので覚えた英単語と組み合わせたりして応用するものいいかもしれません。

逆に、文章を概念につなぐ瞬発力向上には、多読をやりました。 戻り読みをしないという制約で、なるべく意味を理解しながらなるべく速く読みます(85%ぐらい理解しつつ1分あたり何word読めるかのスコアを伸ばす)。 音が明確に聞こえたとしても(つまりテキストとして渡されたとしても)それを読んで理解できるスピード以上には意味理解が追いつかないよねという経験を経てこれも頑張るようになりました。 自分にあったレベルのやつでやらないと途端につまらなくなるので教材選びが大事かも。

音と文章(単語)をつなぐ知覚向上にはシャドーイングをやりました。 英語音源をテキストを見ずに少し遅れて聞こえたまま繰り返すという学習法です。 30秒から60秒ぐらいの音源を1日50回とか繰り返しました… 最初は聞こえないし口がついていかないしで「こんなんできるかボケ」と面談で悪態をついてばかりいたのですが、最終的にはこれがヒアリング力の向上につながったと思っています。 では素直にヒアリング練習で良いのではないかと思えますが、口が回るようになったところが聞こえるようになるという経験を経て、頑張って繰り返すようになりました。 また、多読と並行することで、こちらでは意味理解よりも知覚に集中できるようになったのも良かったです。 以前に比べれば耳の解像度が上がったんじゃないかなあとVersantを前後で受けて見て思えます。

文章(単語)と音をつなぐ発話、発音は今回やっていません。 最初の面談で、まあ全く通じないというわけではないでしょうということで、上記のものを優先して進めました。 とはいえ、実際の発表ではやはりもう少しうまく発音できたらなあと思うこともあったので引き続きやっていこうと思います。

また、オンライン英会話についても(少ししか)やっていません。 本当は実践が一番なのでしょうが、あまりにも引き出しが少ないと英会話の時間が苦痛になるため、英語学習がだれてきた時のカンフル剤としてたまにやる感じにして基礎を頑張りました。


毎日3時間を確実に取れたわけではなく、発表前は資料作成の方へ専念したりもしましたが、それなりの時間を投入しながらも全然使いこなせる感じがしないので、英語学習は奥が深いなあと思います。 それでも続けることで成果は出るので地道にやっていきましょう。

発表資料

資料は一ヶ月ぐらい前から作り始めました。 日本語の元となる資料があることだし十分余裕を持って着手したつもりでしたが、もう少し早くに着手しても良かったなというのが終わって見ての感想です。 理由は母国語に頼らず説明するためには、資料の刷新と英語スクリプトの準備が必要だったからです。 更には、発表練習についても日本語で行う時よりも何倍も時間をかける必要がありました。 ですので、国際カンファレンスに臨むにあたっては余裕を持った準備をお勧めします(実際には渡航のための準備ややるべき仕事もありますし)。

発表資料

スライドの構成は、基本的にプロポーザルの内容に沿うことになります。 先ほどの例であれば、イントロダクション(現状、背景)、提案、評価、まとめの流れが王道でしょうか。

大きなカンファレンスでの発表資料はイントロダクションを少し工夫すると良いかもしれません。 なぜなら同じカンファレンスであっても参加者が多い場合は個々のバックグラウンドや問題意識が多様であり、導入部分で揃えておかなければならないからです。 具体的には、トークの対象となるキーワードや問いなどを簡潔な形で伝えます。 GopherConでは、キーワードを端的に表す写真とともに、「〜のような経験はないか」のような共感を引く導入が多かったように思えました。 僕の資料では、少し前提が複雑だったので、最初の立てた問いをいくつかの実験結果を通して変化させていくような導入にして、より詳しい問題意識を共有するような作りにしました。

また、各所の構成はやや冗長であっても、大枠を示してから詳細に移るのを意識しました。 これは聴衆が置いてけぼりになることを避けるためです。 もちろん母国語の資料であっても気をつけるべきところではありますが、残念ながら、英語力が足りない場合、細かなフォローアップがその場その場でできないこともあり、資料の時点でその工夫はしておいた方が良いと思われます。 簡単な例であれば、例えば解決したい課題が3つあるならば、先に列挙してそれらに番号を振っておくでもいいですし、解決編では先にゴールを述べておくでも良いと思います。 僕の資料では、簡単なアプローチから出発して少しづつ課題を解決していくようにすることで、比較的複雑な箇所の説明の際に飛躍がないよう気をつけました。

図で説明できるものは図を用意する方が良いと思います。 ただし、図に頼って文章を考えなくていいわけではないので、あくまで聴衆の理解を助ける機会をできるだけ増やすという意識で用意します。

細かい点ですが、ページ番号は必ずスライドテンプレートに組み込んでおきましょう。 質疑の時のやりとりがスムーズになります。 また、ページ番号もそうですが、グラフの凡例なども視認できる大きさのフォントにしておくのも大切です(僕のは凡例が小さかった)

僕の発表資料はこちらです。

発表者ノート(英語スクリプト)

英語に不慣れな場合は、一度、発表者ノート(英語スクリプト)を書き出しておくのをお勧めします。 発表者ノートを作成する利点は以下の通りです。

  • 曖昧な箇所や飛躍がある点を潰すことができる
  • 原稿段階で英語話者に並行してチェックしてもらえる
  • 発表の再現性が高まる(特に時間)

いずれも伝えるべきことを全て伝えられるようにするために必要なことだと思います。 そのため、暗記するにしても読み上げるにしても、英語スクリプトは作っておく方が良いでしょう。

Keynoteであれば発表者ノート機能で手元に写しながら発表に臨むことができます。 ただし、演台があるか手元にPCが置けるかなどは事前に問い合わせて確認しておきましょう。

発表原稿では以下を気をつけました。

  • 章や節の始めに、ここでは何を説明するのかを一言で伝える。
  • 章や節の終わりに、ここで伝えたかったことのサマリ、次に何を説明するかを一言入れる。
  • 1ページあたりの文章が多いのであればページの分割を検討する(発表時に発表者ノートをスクロールするのは結構大変)
  • 平易な文で記述する

最後の平易な文については、自分の理解できるレベルの文章でスクリプトを作っておくということです。 発表時は発表者ノートに釘付けで話すわけにはいかないため、さっと見て、ある程度自分自身で意味がわかる文法や単語で構成していないと、強調する文章なのか判断つかずに読み上げる不自然な感じになってしまいます。 不慣れな言語でも自分自身が納得して説明できるように書いておきましょう(残念ながらここの段階で急には英語力は伸びません)。

また、できるだけ英語話者に原稿はチェックしてもらうと良いでしょう。 結構な分量になるので、知り合いに頼むとかよりもできるだけお金を払って英文校正サービスなどでチェックをすると良いと思います。 僕の場合は、先ほどのコーチが買って出てくれたのでお願いできました(コーチによるのでこれを期待してPROGRIT申し込まないように)

僕の英語スクリプトはこちらです。

発表練習

英語に不慣れな場合、暗記かスクリプトの読み上げになってしまいますが、一本調子だと聴衆はどこで共感するか反応するかの情報量が少なくなり混乱してしまいます。 その余裕を持つために、英語スクリプトを自分自身で意味がわかる文法や単語で構成することを提案しました。 それでもまだ目が滑ってしまう場合は、文に区切りを入れるのも良いでしょう。 区切りは関係詞や節の間で適当な単語数のところで入れました(変なところで区切ると逆に不自然になるので気をつけます)

僕の発表者ノートはこんな感じになっています。

I am developing a fast grep tool / named "the platinum searcher".
One day I conducted a measurement / of the optimal number of goroutines / to achieve good performance.

そして、定型の言い回し(I found that など)なるべく流暢にしたり、強調したいところは少しゆっくり大きく言うような工夫を入れました。

ただし、これはあくまで、僕の場合のネイティブの発音じゃない状態で文全体を早口で言うよりはこの方が伝わる可能性が高いねとコーチと試行錯誤した結果です。 つまり「今の」英語力でできるだけ伝えるための工夫であり、本来は継続的な英語の学習によって自然な状態に近づけていくようにすることが大切だと思います。

あとは、英語話者もしくは読み上げ機能で録音した音源を繰り返し聞き、繰り返し練習します。 また、良く出てきたり重要な単語は個別に練習しておくと良いでしょう(僕の場合はperformanceやdetermineなど)

資料のバックアップ

現地の環境がわからないので、資料は複数の手段でアクセスできるようにしておくべきです。 GopherConの場合は、持参したPCとプロジェクタとの接続がうまくいかない場合に備えて、USBメモリにファイルをバックアップしておくよう指示がありました。 僕は発表者ノートが見れない状況を想定して念のため日本でスクリプトを印刷してカバンに忍ばせておきました。 また現地の発表練習では、代替機がMacとは限らないのでPDFや画像ファイルといったポータブルな形式にしたり、クラウドストレージやSpeakerdeckにアップロードしておいたりスクリプトもクラウドストレージにアップロードしてiPhoneから見れるようにしておいてもいいかもねとコメントもらいました。

渡航

アメリカの場合、パスポートの他にESTAの申請が必要なので忘れないようにしましょう。 何もなければパスポートは10日間、ESTAは2週間ほどで発行・承認されますが、ギリギリにやると不測の事態に対応できないため、採択されたらすぐ申請ぐらいでいいと思います。 渡航前は発表練習であまり余裕ないので…

また、海外渡航に不慣れな人は時差ボケを解消する時間も込みで日程を組むことを忘れないようにしましょう。 僕は時差-16時間のサンディエゴで発表でしたが、現地時間の前日入り(日本の7/24 夕方発 現地7/24午前着)してしまい、翌日のお昼すぎ(725 日本時間 午前6時)という時差ボケが激しい時間帯に発表になってしまいました。 @tenntennさんに「なんてやんちゃな日程だ」と言われてしまった… この場合は最低でももう一日前(日本の7/23 夕方発 現地7/23午前着)して、翌日(724)で日中眠らずに現地時間に合わせて当日(725)に合わせるぐらいがいいらしいです。 時差ボケは自分の発表だけでなく、他の発表を聞くときの集中力にも影響してくるのでできるだけ万全の体制で臨めるようにしたいものです。

現地の移動はタクシーではなくUberを使いました。 Uberであれば、アプリから先に行き先を入力し、評価の高いドライバーを選択し、金額を確定しておくことができます。 Comfort系を選ぶとちょっと高いですがゆったりした車になるので複数名の場合はそちらを選ぶと良いみたいです。 サンディエゴだと大体10分ほどで来てくれます。 ドライバの現在地、車種とナンバーが事前に分かっているので、それを探します。 また、アプリは画面に色がつくので、その画面を振ってドライバに見つけてもらう感じです。 移動はアプリで現在地が分かるため安心です(そもそも事前に金額確定なので遠回りして稼ぐような動機がない)。 日本でアプリをインストールし、クレジットカードまで登録しておくと良いでしょう。 それから、自分のアカウントにきちんと顔写真登録しておく方が良いみたいです(ドライバーさん側への安心感かな?) 決済は到着後にプッシュ通知が来るのでチップの額を上乗せして終了です。便利便利。

発表

あとはこれまでやって来たことを信じて発表するだけです。 せっかく自分の提案を国際カンファレンスで聞いてもらえる機会なので楽しんでいきましょう。 会場の雰囲気はとても良く、とても積極的に聞いてくれます。 なぜならカンファレンスに来ている人は、上手い下手をジャッジしに来てるのではなくて、僕たちの提案を経験をできるだけ聞きたいと言う姿勢で来てくれているからです。 どうしても緊張する人は、前方の10人だけをターゲットに最初の挨拶を元気に言うことだけ考えましょう。 あとは練習した通りに体と口が動いてくれます。

発表後は、おそらく色々なところで質問や感想のために声をかけてもらえます。 これはスピーカーとしてカンファレンスに参加したときの特典なので是非とも活かしたいところです。 ですので、余裕があれば想定問答や提案のサマリ、自己紹介などを事前にまとめておくと良いと思います。

GopherCon 2019で初の海外カンファレンス登壇をしてきました

7/24から27にかけてアメリカ、サンディエゴで開催されたGopherCon 2019で人生初となる海外カンファレンスに登壇してきました。

GopherConはGo関連で最大級の国際カンファレンスです。 6年目となる今年は世界中から1,800名のGopherが参加し、200名以上の応募の中から選ばれた36名がスピーカーとして登壇しました。 今回のGopherConではPre-Conference Workshopと呼ばれるカンファレンス前日に終日行われるワークショップと、カンファレンス期間中に行われる25分のキーノートセッション、そして45分のチュートリアルセッションがありました。 その中で、僕は「Optimization for Number of goroutines Using Feedback Control」というタイトルで45分のチュートリアルセッションを務めました。

動画

スライド

スピーカーノート

発表内容

今回の発表は以前東京で開催されたGo Conference 2018 Autumnで発表したフィードバック制御によるGoroutine起動数の最適化を英語化したものです。 また、今回向けに実際にThe Platinum Searcherに組み込んで有効性を評価する実験結果を追加しています。

発表資料については、45分という時間で母国語を使わずにできるだけわかりやすく伝えるため、結果的にほぼ刷新する形となりましたが、母国語の慣れに頼らずとも説明可能なわかりやすい資料になったのではないかと自分では思っています。 具体的には、まずイントロダクションとバックグラウンドの章を少し手厚くしました。 今回の手法は、フィードバック制御を用いてgoroutine数を継続的に最適に保つことを目的としています。 しかしながら、そもそもGo言語の並行処理においては、goroutineのコストの低さとランタイムがgoroutineを効果的に切り替えることから、その必要性はないのではないかと考えることができます。 そこで、リソース競合や枯渇などの影響も受けてしまう可能性があること、それらを考慮した汎用的な並行設計に対する難しさを、実際にプラチナサーチャーによるパフォーマンスチューニングの例を踏まえながら前提を合わせるようにしました。 また、手法の説明では、簡単なアプローチから出発して少しづつ課題を解決していくようにすることで、比較的複雑な箇所の説明の際に飛躍がないように気をつけました。

発表について、普段は資料のみで臨んでもそれなりに話せると自負していますが、初の英語での登壇となるため今回は発表内容のスクリプトを用意して、伝えるべきことを全て伝えられるようにしました。 また、不慣れな言語でも自分自身が納得して説明できるように、できるだけ平易な文で説明することで、発表資料と同様に曖昧な箇所や飛躍がある点を潰すことができたと思います。

本番の発表は、4スクリーンある300-400人規模の会場ではありましたが、とても熱心に頷いてくれる方がいたり日本から来たメンバが前に座っていたりして、幸いにも落ち着いて自分のペースで登壇することができたと思います。 発表では、あまり一本調子にならないように、文の中でも意味や文法上切れる箇所は間をおいたり、定型の言い回し(I found that など)なるべく流暢にしたり、強調したいところは少しゆっくり大きく言うなど、「今の」英語力でできる工夫をしていきました。 一方で、個別の単語の発音などはまだまだ課題意識があるので、今後、そちらも重点的に取り組んでいきたいと感じました。

質疑の時間は登壇時間には含まれなかったのですが、終了して台を降りると同時に7人ぐらいに囲まれて質問責めに会い、発表に興味を持ってくれたことをとても嬉しく思いました。 質問としては、発表内容について理解があっているか確認するものと、実装上の質問などがあり、資料やKaburayaのコードを見ながら説明していきました。 それでも、今の英語力では、発表内容以外の部分については拙い説明になることも多々あり、これも今後改めて英語をやるモチベーションが高まりました。 また、発表後もカンファレンス期間中に何度も感想や質問をもらう機会があり、これがとても嬉しかったです。

会場と発表の様子

発表に関する反応

カンファレンス

会場はカリフォルニア サンディエゴのホテル Marriott Marquis San Diego Marinaでした。 サンディエゴが比較的温暖な気候であること、ホテルもいわゆるリゾートホテルのような感じであったことも手伝って、期間中はとても快適に過ごせました。

GopherConのタイムテーブルは朝が早いものの(最初のセッションがAM9:00から)、2-3セッションごとに30-40分の空き時間が設けられており、この時間に登壇者とディスカッションしたり、ポップアップミーティングスペースやスポンサーブースでコミュニティや企業への関係を作ったりすることができました。 日本でも学術系のシンボジウムだとこういったタイムテーブルは見かけるものの、GopherConではより積極的に関係を作っていこう、そしてそのために運営がその接点を作る機会(場所、時間)やホスピタリティを提供していこうという気概が感じられました。 また、Welcome Partyが本物の空母の上で開催されたのはめちゃくちゃ驚きました。こういう「楽しんでるぞ」というのが一貫して感じられるのも良かったです。 実際に #gophercon ハッシュタグを追っていると、たくさんの知見や関係を得たという感想と合わせて一種のバケーションを楽しんだような満足感を持っている方が多かったようです。 ちょうど、GoCon福岡を2週間前に開催したところであったため、「カンファレンス」をどういう設計で進めるのかという観点はとても勉強になりました。

トークについては、どれも最新の情報だけでなく、スピーカーの方の実際の経験に基づく興味深く、かつ面白いセッションばかりでとてもためになりました。 それでも、自分の発表前後の緊張や疲れ、時差ボケなどで万全の状態で全てを聞くことはできなかったのが悔やまれますが、幸い個別のトークについては今後動画も公開されるようです。 Agendaを見て興味あるセッションを是非ご覧ください。

スピーカーディナー

発表は7/25でしたが、実は7/26の夜にスピーカーディナーなるものが控えていました。 登壇者ばかりが集う3時間の立食パーティーを英語で乗り切るという、ある意味では登壇よりもプレッシャーのかかるイベントでした。 それでも、とてもよい機会であるし無駄にはしたくないと、できるだけ話に加わり自分の意見や要望を伝えることができたと思います。 特に日本や福岡のコミュニティ活動やカンファレンスに何人か興味を持ってもらうことができたのは非常に有意義でした。 また、ワークショップを担当したエンジニアの方とは日本に戻ってからも連絡を取り合っており、今後何か面白いことが一緒にできるといいなあと考えています。

とにかくこの3時間は僕の英語に対する心理的な苦手意識を取り除いてくれる絶好の機会となりました。 同時にやはり英語力の足りなさを痛感したことで、引き続き英語もやっていきたいと強く思えました。

おわりに

2014年の東京のGoConference 2014 springで発表したのが僕にとって初めての全国区のカンファレンス登壇でした。 そこから、自分のキャリアや興味範囲が広がっていく中でも、Go言語はずっと相棒として付き合ってくれる言語でしたし、Go言語を中心に色々な付き合いができていると感じています。 また、ここ数年の研究職としての試行錯誤がなければ今回の発表内容はありませんでした。 その意味で、今回のGopherCon 2019は現時点の僕の集大成で臨んだカンファレンスとなりました。 幸いにも、発表に対して興味を持ってもらえたこと、一定の反響があったことを、非常に嬉しく思っています。 同時に、このような大きな海外のカンファレンスで発表できたことは(2014にGoConで発表した時と同じように)素直に自信につながりました。 (当日聞いたのですが、スピーカーのうち、ワークショップを行われた約10名の応募枠は別だったとのことで今回は改めて狭き門を抜けることができたんだなあと感じています)

この登壇に向けてアドバイスや協力をいただいた皆様、本当に感謝いたします。 このカンファレンスで得た様々な知見や関係、そして至らなかった点は次へ活かし、この契機となったGoコミュニティの活発化に繋がるよう引き続き”楽しみながら“やっていきたいと思います。

俺たちが日本代表だ!

gophercon_japan

LTセッションで登壇した@hajimehoshiさんと@hgsgtkさんと共に。


そして最後に、Russ Coxと隣に扱われる機会ってそうそうないので記念にスピーカー一覧のスクショを置いておきます、えへへ。(ただのアルファベット順だけど)

gophercon_russ

福岡でGoConを開催した

7/13にGo Conference’19 Summer in Fukuokaを開催した。 諸々落ち着いたので、初めて200名規模の大きなカンファレンスを開催するまでに駆け抜けた日々を振り返っておく。

準備

Fukuoka.goの主催の一人としてGoConの福岡開催は是非ともやりたい気持ちがあり、Go Conference 2018 Autumnで登壇した際の懇親会で盛り上がったのが去年の11/25。

  • 11/30にFukuoka.go運営でやっていきのIssue起票。
  • 12/04に会場と時期のおおまかなあたりがついたので正式にGoCon地方開催を東京GoCon運営に打診。
  • 12/14に企画書を元に関係者に一通り話しが通った状態へ。

と良い感じのスピード感で進み出し、後は運営スタッフ一同で

  • 1月はマスコットのデザインやらLPの準備やら
  • 2月はGo1.12のリリパでイベント開催を初めて告知。GoCon運営スタッフも増えた。
  • 3月はCfPをオープン。スポンサー内容や金額感について具体的な検討と募集を始めた
  • 4月はCfPへのアーリーフィードバック、CfP草の根宣伝活動、スポンサーとの個別やりとり
  • 5月はCfPの選考と結果通知、タイムテーブルと参加枠を決めてconnpassを公開。
  • 6月は集客草の根宣伝活動、Tシャツやバックパネル、会場の軽食や飲み物、スピーカーディナーなどについて検討・確認・発注
  • 7月は当日までの作業の整理をして確定していないものを一つづつ対応(受付方法、司会進行、会場レイアウトや設営日、名札作成、ノベルティ配布準備、アンケート、市長、段ボール、張り紙 etc)

と、ひたすら準備を進めた。 大規模カンファレンス開催のノウハウがない中でも、準備は共同主催の@linyowsが皆を引っ張った。 作業分担は、@linyowsが打ち出したデザインやおもてなしの世界観に皆がイイねをしながら、できる人が具体化を進めていく形に落ち着いた。 @linyows自身がガンガンとタスクをこなしていく(会社では傭兵と呼ばれている…)ので、僕自身は具体化を担当する他、方針の見直し案や進捗整理からの抜け漏れ対応といった補佐役に徹した。 @seike460をはじめとする運営スタッフとSlackでワイワイしながらだんだんと形になっていく過程も含めて(大変だったけど)楽しめたと思う。 開催時期については会場都合で少し延ばして7月としたが、今思えばこれぐらいの準備期間がないと納得いく形にするのは無理だったかもしれない。


個人的に大変だったのは、連絡まわりで、いくつかの連絡経路を使ってたくさんの関係者と個別または全体で効率よく相談、告知するのは骨が折れた。 他のカンファレンス運営でどういう風にやっているのかを聞いてみたい。 反対にCfPの選考は多様なプロポーザルを見る機会として有益であったと思う。 また、より良いプロポーザルにするためのアドバイスをアーリーフィードバックという形で進めることができたのも非常に良かった。 特に、このフィードバックを通してプロポーザルの説得力が格段に上がっていく例などを見るのは嬉しかった。

準備は前日と当日の朝が一番大変であった。 会場のリニューアル直後であったことも手伝い、搬入されるスポンサー物品を含む会場設営などはその場で詳細を決定して進めなければならなかったため、開場までの時間がない中で慌てて進めた。 特に当日朝は雨がすごかったので準備頑張ってるぞ感がすごかった気がする。

当日

当日は幸いなことに@linyowsと僕は専任のタスクを持たずに各種ジャッジや遊撃手的な動きをできたことで全体に柔軟に対応できたと思う。 受付がひと段落して、高島市長のスペシャルセッション前後の応対が終わって、ビールや生ハムの提供が軌道にのるまでは、イベントがスムーズに進むように、心地よく過ごしてもらえるように裏側では様々な物品や情報が行き交っており、とにかく忙しかった(けど何をやったかは覚えていない)みたいな感じだった。 これが16:00ぐらいで、ビールが入ったこともあって一瞬寝落ちしたのを写真に撮られてしまった。

gocon_00

この後、少しだけセッションを聞けたけども、楽しみにしていたセッションをほぼ聞けなかったのでここは次への課題だねと振り返りで話した。 セッションは最後まで盛況で、懇親会まで盛り上がっていたので嬉しい気持ちで眺めていた。

僕たちのソフトウェアの仕事は作った後に動く期間が長いので、こういった半年以上の準備とわずか1日のイベントという形式の経験はなかなか貴重だったし、大変ながらも充実した時間を過ごせて楽しかった。

スピーカーディナー

カンファレンス後のスピーカーディナーでは豪華なメンバと素敵な料理に囲まれてこれまた楽しいひと時であったものの、各種支払いや幹事的な動きをしていたらあっという間に終わってしまったので、ちょっと残念だった。 ただ、テーブルの右も左もみんなが新しいつながりを作って飯食って酒飲んでGoの話して笑っているのを見て、「アーーーこれはやって良かったんではーーーーーー!!」と一人泣きそうになっていたのは秘密である。

カンファレンスを終えて

まず、@linyowsにスタッフ一同からお礼を伝えたいです。ありがとう! 今回のイベントは@linyowsなしでは考えられない。 @linyowsの行動力、大人力に対して尊敬の念が更に高まりました。Fukuoka.goを共同で主催してくれることが非常に心強いです。これからもよろしくお願いします。

そして、改めてスタッフの皆様、スポンサーの皆様、発表者の皆様、参加者の皆様に感謝を伝えたいです。ありがとうございます!

カンファレンスへの想い

どうして集う形の勉強会やカンファレンスにするかというのは、何度か聞かれていて、この辺りでも答えていたのだけど、まず単純に集まって楽しく話す仲間がいることの嬉しさがあって、その背景として「場やコミュニティは実在しないので。定期的にやることが大事」という考えがあった。 コミュニティというネットワークを継続させていくためには、接合点である参加者の間の接続を活性化する必要がある。 そのためにはネットワークが活性化するように情報を行き交いさせるんだけれども、均等な一方向の情報発信は刺激に乏しいこともある。 人間も単純な部分は残っているので、実際に会ったとか、その場の熱量とかに影響されて発信側も受信側も一時的に接続が活性化する。 こういう励起された状態は、例えばカンファレンスを地元でやろうとか、触発されてツールを作って見たとか、ネットワークへの新しい情報の元になってコミュニティに還元される。 勉強会やカンファレンスは、そういうやり方での重みの活性化を担っていると思う。

今回のカンファレンスがGo言語コミュニティや福岡にとって上のような影響を与えることができたのであればとても嬉しい。 何より、カンファレンス運営を通して、スタッフみんながエキサイティングな経験を楽しんでいたことがとても嬉しい。 なぜなら、僕たちが楽しみ続けることがまず大事だから〜〜。お疲れ様でした!!!

そしてオフィシャルのイベントレポートが非常によくまとまっています。こちらも是非ご覧ください!

フォトギャラリー

最後に、誰得 モノクロメガネ フォトギャラリーを置いておきます。いやぁ、楽しんでるなあ〜

gocon_01 gocon_02 gocon_03 gocon_04 gocon_05 gocon_06 gocon_07 gocon_08

Photo by @atani


𝝣Go

Archives