THINKING MEGANE

2019

今年は研究とGo言語三昧だった。 特にGo言語については、福岡でGoConを開催し、GopherCon2019で初の海外カンファレンスに登壇した。 大規模カンファレンスの主催も海外の大きなカンファレンスでの登壇も初めての経験で準備もプレッシャーも大変だったが、多くの人と笑いながら協力しながらなんとか達成することができたと思う。 これらの経験は自分の行動の幅を世界基準に広げるにあたって大きな自信につながった。 加えて、コミュニティ活動として主催するFukuoka.goを他の地方コミュニティと同時開催したり、Go言語教室を招いたり、OSS Gateのメンター、Fukuoka.LTの運営をやったりと精力的に福岡のコミュニティを全国とつなげ、盛り上げることができた。 来年もGo言語を武器にどんどん活動していきたい。

研究については、当初目標だったジャーナルには残念ながら不採録となったものの、改めて研究を発展させ年内に再度投稿することができた。 今年執筆した論文とそのフィードバックから、研究の背景(動機、位置付け、従来課題の整理)は一定のレベルで書けるようになったのではないかと感じる。 一方で、提案手法とその評価に関する指摘の割合が多くなってきており、改めて提案手法の貢献を明確にできるよう考え抜いていかなければならない。 これまでの研究を通して「常に変化しうる多数の環境に対する自律適応的なシステムとその仕組み」が背景にあるのではないかと考えており、来年はこの観点でのサーベイと体系化を進めていきたい。

2019年をかけて、多くのことを達成することができた。 特に精神的な面では強くなれたのでないかと思う。 上期の前半は、研究で実績が出ないことに対する焦りや力不足でまたも袋小路に入ってしまったが、アドバイスや助力いただけたことで立て直すことができた。 それでも、何かをやることに対する漠然とした恐怖や、過度な専念などいくつかの弱体化がかかっていたように思う。 結局は、無能だと判断されたくないだとか、集中することができれば大きな成果を出せるはずだとか、心の奥底に対外的な評価が中心に据えられて、自己評価とのギャップと相まって動けなくなっていたことが原因だと思い至り、過去の理性の人のエントリを見返しつつ、自分を大切に、なすべきことをやっていけるよう少しづつ冷静になれた。 周りからの評価を恐れてやるべきことを見失ったり曲げてしまうのはとても悲しいことだし、 生きている以上、やることは常に発生するのだから、これらを後回しにすることは長期的には専念にはならないし、 色々なことに向き合う必要があるのだから、人や結果に過度にひきづられることを言い訳にせずに個々の事象をある程度独立させて淡々とこなして行くのが良いのだろう。

来年は、数学、英語、サーベイを継続的にこなしつつジャーナルを通して博士課程に挑戦する。 また、トップダウンの視点をもって行動の意義を共有することで影響力を高めていこうと思う。 2020年もよろしくお願いします。

実績

以下、実績を列挙する。

論文

国内査読無し論文が2本と国内査読付きポスター発表が1本。執筆としては査読付き論文が2本。うち1本が不採録で、投稿中が1本。

  1. 三宅 悠介, 栗林 健太郎, Kaburaya AutoScaler: 多環境での運用性を考慮した自律適応型オートスケーリング制御系, インターネットと運用技術シンポジウム論文集, 2019, pp.114-115, Nov 2019. [論文] [発表資料]
  2. 三宅 悠介, 阿部 博, 栗林 健太郎, なめらかなセキュリティを目指して, 研究報告インターネットと運用技術(IOT), Vol.2019-IOT-47, pp.1-7, Sep 2019. [論文] [発表資料]
  3. 三宅 悠介, 松本 亮介, 利用者の文脈に応じて継続的に推薦手法の選択を最適化する推薦システム, 研究報告インターネットと運用技術(IOT), Vol.2019-IOT-45, pp.1-7, May 2019. [論文] [発表資料]

国外発表

初の海外カンファレンス登壇。めでたい!

国内発表

技術イベント、研究会での発表で計6回。

  1. 三宅 悠介, コマンドラインオプションをパースするコードをコマンドラインオプションから生成するツールをつくった, Fukuoka.go#14+Umeda.go, 2019年10月.
  2. 三宅 悠介, Kaburaya AutoScaler: 多環境での運用性を考慮した自律適応型オートスケーリング制御系, 第五回 Webシステムアーキテクチャ研究会, 2019年9月.
  3. 三宅 悠介, 「エンジニアコミュニティの運営について」パネルディスカッション, Engineer Friendly Space, 2019年7月.
  4. 三宅 悠介, AI(機械学習)ワーキンググループ 成果報告, ペパコンナイト, 2019年5月. [動画]
  5. 三宅 悠介, Ebira: アクセス負荷に応じて継続的にスケーリング基準を最適化する汎用オートスケーリング機構, 第四回 Webシステムアーキテクチャ研究会, 2019年4月.
  6. 三宅 悠介, Go language serverを理解する, Go 1.12 Release Party in Fukuoka, 2019年2月. [動画]
  7. 三宅 悠介, dragon-importsで爆速goimports生活 - プロジェクト Go modules, Fukuoka.go#13+Okayama.go, 2019年2月.

OSS

Kaburayaを中心に自律適応的な仕組みに向けての知見を深めていった。また、研究系のシミュレーションが増えてきた。

コミュニティ活動

Goを中心に精力的に活動できた。特に全国規模のカンファレンスを福岡で主催したり、地方のGoコミュニティ同士を繋いだり福岡以外へも活動の幅が広がっている。 また、OSS GateやFukuoka.LTへの参加を通して福岡全体の盛り上げにも協力できたかなと思う。

出版物等への寄稿

前作に引き続きガッツリと査読に関わらせていただいた。

  • 書籍査読: スマートニュース株式会社 立石 賢吾, やさしく学ぶ ディープラーニングがわかる数学のきほん ~アヤノ&ミオと学ぶ ディープラーニングの理論と数学、実装~, マイナビ出版, 2019年07月31日. ISBN:978-4-8399-6837-3

ブログ

13本。一時期は日記を書いていたが、考えをまとめる練習にはつながらなかったかもしれない。 実績に加えてどうしてそのような活動に至ったのかについてもトップダウンの視点で書いていきたい。

論文執筆の道しるべ

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

  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

Archives