THINKING MEGANE

なめらかなシステムの見据えるもの。個人的考察

ペパボ研究所ではシステムの利用や運用における様々な障壁を取り除いた、なめらかな利用や運用を目指して研究を行っている。 本稿では、なぜなめらかでなければならないかの問いを端緒とし、定義の解釈を試みることで、なめらかなシステムの見据える未来について考察する。 考察を通して、なめらかなシステムの見据えるシステム観を再認識し、システム設計の道標にするとともにそれらの普及した場合への対処としてのなめらかなシステムの有用性を確認する。

なめらかなシステムを解釈する

なめらかなシステムを構成する要件

ペパボ研究所では、システムの利用や運用における様々な障壁(ゴツゴツ)を取り除き、利用の快適さや運用における生産性の向上に繋げるため、以下の「なめらかなシステム」を提案、実現に向けた取り組みを進めている。

「なめらかなシステム」とは、情報システムのことをいうのみならず、互いに影響を及ぼし合う継続的な関係にある利用者(ユーザーおよび開発運用者)と情報システムとからなる総体としてのシステムであり、以下の要件を満たします:

1. 利用者と情報システムとが継続的な関係を取り持つ過程において、利用者それぞれに固有のコンテキストを見出したり、新たなコンテキストを創出したりできること
2. 要件1.を、利用者による明示的な操作を課すことなく実現できること
3. 要件1.および2.によって得られたコンテキストに基づき、情報システムが利用者に対して最適なサービスを自動的に提供できること

ref: https://rand.pepabo.com/

すなわち、システム総体における要素の状態、状況、条件といった「文脈」が暗黙的に認識され、文脈ごとに最適な振る舞いが提供されるシステムである。 ここで、なめらかなシステムは上記の要件をすべて満たす必要があることに注意したい。 特定指標の予測や限定的な自動化はなめらかなシステムを構成する基礎技術ではあるがそれ単体ではなめらか足り得ない。

なぜなめらかでなければならないか

なめらかなシステムを実現するにあたっては、文脈をシステムで利用可能な指標に落とし込み、これを暗黙的に獲得し、この文脈指標に適応した振る舞いを定義しなければならない。 このように、なめらかなシステムは利用者や運用者への利益をもたらすが、同時に複雑性も持ち込む(システム操作に含まれない過去の経験や状況まで含めた文脈と指標の紐付けが困難であり、そのためのログ基盤、機械学習基盤、予測フィードバック機構の整備が大変なことは同意いただけるだろう)。

そのため、なぜなめらかでなければならないかを明確にし、その必然性から適用を検討すべきであると考える。 我々はなめらかなシステムの論文化(論文と発表資料)にあたり、従来の定義を洗練し、システムの利便を得るべき人間の存在をシステム総体のうちに組み込むことを明示した。 これにより、このような人間は、様々な文脈を持つこと、そして情報要求がコミュニケーションによって逐次変化していくことに着目し、情報システム側もこれに追従する仕組みが必要であると述べた。 すなわち、様々な文脈を持ち、変化し続ける対象としての人間の存在を以って、これに対応するためのなめらかなシステムの必要性を主張した。

一方で、なめらかなシステムでは、利用者やシステムコンポーネントなどは振る舞いを持って役割とし、本質的には等価にみなすことができると考える。 であれば、様々な文脈を持ち、変化し続ける対象としての人間の存在を解釈し直すことで、なめらかなシステムを適用すべき対象を定義することができるのではないか、というのが本稿の主旨である。

利用者を解釈する

個性を持つ存在として捉える

ここでは、様々な文脈を持ち、変化し続ける対象としての人間を「個性」という観点で汎用化を試みる。 そのために、利用者が様々な文脈を持つことと複雑性の関係について見直したい。 様々な文脈を持つことを何らかの方法でシステム的に取り扱える指標に変換できた場合、それは多次元の特徴量として表現されるだろう。 これらを以って振る舞いを定義する必要がある場合に、必ずしもすべての特徴量の組み合わせに対処するように定義しなければならないかといえばそうではない。 情報要求の満足度に対する各次元の寄与度は均等ではないはずで、一定のパターン数での対応で現実的には可能であるように思える。 実際、少なくとも現状のシステムは部分的には制御可能なパラメタのもと、ヒューリスティックな対処がまだ有効な範囲内で行われていることからも言えるだろう。 もちろん、様々な文脈としての特徴量の次元数が多いことは複雑さの増加には繋がる。 しかしながら、複雑であるとしてみなさなければならないのは対応パターン数ではなかろうか。

本稿では、このような対応パターン数を増加させる対象を「個性を持つ」と表現したい。 ここで、「個性を持つ」とは、ある面では同じクラスタに属しながらも同じ入力に対して異なる振る舞いを行うことだと定義する。 これには、人間はもちろんのこと、クラスとインスタンスの関係のように、異なるデータで学習した機械学習のモデルなどがあるだろう。 このような対象に対するコミュニケーションは傾向はあるとしても正解はなく、対象や文脈を仮定しながら試行を繰り返し歩み寄っていく必要があるはずだ。 そして、そのような歩み寄りの過程こそがなめらかなシステムの構成要件であると言える。

概念の獲得が個性をもたらす

集団における共通項として概念が獲得されることで概念を満たす内部実装が多様化し得るのではないか。 共通のインターフェースを持ちながらに、別の面では振る舞いに差が現れる。 人間は自身の感覚器からの情報を生で知覚するのではなく、(おそらく)多層の抽象化、概念化を通した結果として知覚する。 また、個々が理解している概念の表層として言葉を操り、(おそらく)同じような理解をしているであろう対象とコミュニケーションを行う。

これまで機械としてのシステムは、個性が生まれるように設計されたものがそのように振舞っていた。 しかしながら機械としてのシステムが互いに共通インターフェースである概念や定義を獲得し、それを満たす実装や解釈を行うようになれば個性の爆発が起きるのではないかと思う。

わからないものとして扱う

ここではなめらかなシステムの実現にあたっての実装寄りのアプローチについて検討する。 個性を持つシステム要素はその性質上、相互にわかり合うことはできないため、なめらかなシステムのようなアプローチを通して歩み寄らなければならない。 このような「わからない状況」をシステムとして扱うためには、単体の手法ではなく状況に応じたいくつかの方法論の組み合わせが有効であろう。 まず入力の大局や傾向については回帰や機械学習などからなる予測的なアプローチをとり、予想外の入力変化に対しては例えばフィードバック制御などの脊髄反射的な対応が求められる。 次に、入力に応じたパターンの選定では、なめらかなシステムが前提とする対象において、無限のパターンが想定されることから、実運用環境での最適化が必要である。 具体的には多腕バンディット問題として取り扱ってもよいだろうし、進化的、遺伝的アルゴリズムを用いた解法も選択肢に入るだろう。 このパターン選定のための最適化アプローチは多くの試行を要するが、対象をシステム要素とみなす場合はその労苦は考慮不要であるし、 人間を対象とする場合であってもシステム利用者全体の操作を束ねたものを利用すればよいだろう。

なめらかなシステム再考

ここまでの考察から、なめらかなシステムは個性を持つ対象とのコミュニケーションが発生する状況において求められ、これに継続的に適応可能なアーキテクチャのことを指すと考えられる。 例えば、推薦システムは、人間を対象とし提示した推薦結果に対する反応が異なることことから、なめらかなシステムの適用先の事例として考えやすいであろう。 では、なめらかなオートスケーリングはありうるか。 特定サービスの単一メトリクスに基づいてルールベースの増減するような場合、例え入力に多様性があっても、システムとしては決められた挙動を行うだけであり、動的制御であってもなめらかではないことは自明である。 一方で、オートスケーリングの指標において、より抽象的な概念である、キツい、ダルい、調子良いのような言葉を以って、いい感じに振る舞うことができるとすれば、そこには解釈の余地が生まれ、入力への対処の自由度、すなわち個性を持った対応が必要になる。 また、非常に複雑なシステムにおいて増減自体が他へ与える影響が読めないような場合にいい感じに落とし所を見つけなければならないのであれば、そのような状況も個性を前提としたものであろう。 このような対応パターンの増加に対するアプローチは先に述べた通りであるが、概念の創出とパターンに対する最適化は相互に洗練していくことになるだろう。

まとめ

本稿では、なぜなめらかでなければならないかを問いの発端とし、システムの利便を得るべき人間について個性の観点から再解釈することで、なめらかなシステムの見据える未来を明確化した。 なめらかなシステムについての考察は、完全にこれを実現した突出したシステムが突然表出するわけではなく、システム総体に含まれる要素が相互に徐々に複雑化していく過程で、これに対応する必然性から最適化が行われ、 さらにその複雑性が、個性を育てるというような、今後のシステムの進化そのものを想起させる。 であれば、システム設計において進化の方向性としてこれを意識することで、従前の単なる自動化や動的制御の先を見据えた発想になるのではないか、その環境においてどのように対応すべきかを考える道標となるのではないか。 本考察が、その一助となれば幸いである。

わかるとわからないの間

元来が完璧主義である.理解できない場合にはレイヤが異なっていたとしても大部分がソースコードやプロトコルとして定義されていて掘り下げて調べていくことで挙動が把握できるようになるソフトウェアエンジニアは性に合っていた. ところがここ数年は推薦システムに興味を持ち,あまつさえ研究として取り組もうとしたものだから,人間の認知プロセス解釈の果てしない旅に途方に暮れてしまった. 理解できていない状態が自信の無さを招き,自説を守りきれずに論文を落とした.

それでも対象の推薦システムの実装やKaburayaの構想を進める中で,現状把握できる部分的な情報や結果を元に適応していくアプローチが十分有効になり得るのではないかと思え始めた. このようにある意味「わからない」を取り扱うアプローチは,工学的な方法だと一般的なのかもしれないが,多くの部分を把握できる可能性があるソフトウェア分野の経験からは新鮮であった.

今は,とにかく提案システムの有用性を示していく段階ではある.ただ,「わからないから進めない」を脱することができたことが素直に嬉しい. さらには,起点を作れたことで「わからない」分野に対して挑む方針も固まってきた.「わかるために進む」のは気持ちが良いものだ.

わからない場所に踏み込む.本当にいつも遠回りばかりしている気がするが,ようやっと研究の入り口に立てたのかもしれない.


もちろんソフトウェアだからわかる,人間だからわからないというのはいささか短絡的である. 単純なものから複雑なものへの発展の経過を追うことが可能であるがゆえに理解ができているのであって,ソフトウェアであっても巨大で変化の激しいシステムは経緯を含めた全容の理解は困難になる. 反対に人間の認知であっても高次の抽象レベルのみで正確な疎通が可能な概念であれば相互理解は可能であろう.

拠点間勉強会を接続するリモート勉強会への誘い

主催するFukuoka.goは今月2回のリモート勉強会を実施しました。リモート勉強会に関心のある主催者の参考になればと思い、このエントリではリモート勉強会の開催に関するハウツーと利点、課題を整理します。タイトルは”いざない”と読んでください。雅ですね。

経緯

私は福岡在住です。前回のGoConで東京に発表しに行った際に、岡山の岩田プロとお話しする機会がありました。 知り合えたのも何かの縁、福岡と岡山で何か面白いことやりましょうとふわっと約束したのを覚えています。 福岡への帰路、イベントのアイディアを考えながら、やはり物理的な距離の制約が面倒だなと思い至りました。 幸い、所属するGMOペパボでは東京オフィスと福岡オフィス間を繋いだ勉強会(PTF)を定期的に開催しており、この方式を社外の勉強会に転用するという着想を得ました。

Fukuoka.go#13+Okayama.goと銘打ったイベントの準備は順調に進み、当日は、両会場からの発表を行い会場を挟んだ質疑応答のコールアンドレスポンスも楽しめました。 気を良くして数日後に東京で行われたGo1.12 Release Partyにも接続させてもらい、東京会場の発表を聞いたり、福岡からも発表を行いました。当日は大阪会場も接続していたようです。 各回、各会場とも満足度が高く成功だったと言えるでしょう。

以下では、これらのリモート勉強会を通して得たハウツーや考察を紹介します。リモート勉強会の開催に興味を持った方は良ければ参考にしてください。

1. リモート勉強会とは

このエントリでは、勉強会を、一定人数が会場に集まり発表者の登壇を参加者が聴講し、必要に応じて質疑応答がなされる形式のものとします。 そして、リモート勉強会とは、そのような複数の勉強会会場がインターネット越しに音声と映像を双方向に中継され、同期したタイムテーブルの下で進行される形式のものとします。

2. 接続方式と構成

接続

拠点間接続にはビデオ会議サービスを利用します。音声、映像、そして画面共有ができるものが必要です。 さらに参加時の敷居を下げるため特定のアプリケーションに依存せずブラウザ単体で動作するものが望ましいと考えます。 今回はこれらの要件を満たす、Google Hangouts Meetを利用しました。

Hangouts MeetはG Suite利用者のみミーティングを作成することができますが、Googleアカウントを持っていれば(許可制ではありますが)G Suite利用者以外のアカウントも参加することが可能です。

構成

会場ごとに少なくとも1台のPCから会議に参加している状態とします。会場参加者の映像や音声を伝えるのはこのPC(と外部接続のカメラやマイク)が担当します。 また発表資料のあるPC上(一般には発表者の個人PC)からも同様に会議に参加しておきます。会場の音声が重複することを避けるため、発表者PCではマイクをオフにしておきます。 映像は自由ですが、だいたい他の人の発表を聞いている時の間抜け面が全会場に配信されるため、特に理由がない限りカメラもオフにしておくと良いでしょう。 発表時は、発表者のPCから画面共有を行い、資料を全会場で閲覧できるようにします。

小さい会場の場合は会場のPCと発表者のPCが兼業することになり、より直感的に準備が進むと思います。 大きな会場の場合は、会場のPCとカメラやマイクの外部接続が必要になります。ここについては共同主催者の@linyowsが別途、「リモート勉強会を支えるオーディオ技術」としてエントリを書いてくれるはずです。読みたい!

なお、これまでの開催を通して、各会場のカメラは、登壇者を写すもの、会場の様子を写すものの2つがあると一体感が増すように感じました。 そのため各会場からはこれを担う2つのPCが会議に参加していると良さそうです(マイクは一台のみオンとする)。

3. リモート勉強会におけるリモート会議サービスの実用性

現在のリモート会議サービスであれば十分リモート勉強会で利用することは可能だと考えます。

特に、このエントリで定める勉強会方式、つまり情報の向きが単方向でシーケンシャルに制御されている、登壇と質疑応答のような方式にはビデオ会議サービスは非常に適していると思えました。 個人的には現実の会議ではリモート会議越しだと視線や挙動をうまくつかめずに同時に話してしまったり逆に沈黙があったりとまだ少しだけ違和感を感じますが、登壇形式であればそのような状況はあまり発生しません。

また、別会場の音声が聞き取りにくいとストレスを感じますが、少なくともGoogle Hangouts Meetを使用している限りでは接続は非常に安定しており、ここを課題と感じることはありませんでした。 ただ、音声機器に関してはPC内蔵マイク/スピーカーと外付け機器を比較した場合、品質向上はもちろんのことボリューム調整なども容易になるため、予算に応じて良いものを手配した方が良いと思います。 関連して、Google Hangouts Meetの設定で外付け機器が適切に選択されていることも確認する操作も準備の際に忘れないようしたいところです(今まで二回ともこれでハマっている)

準備についても初回こそ念のため別日に接続リハーサルを行いましたが、2回目からは初めての会場同士であっても開始1時間前に接続して音量チェックを行う程度で十分間に合いました。

4. リモート勉強会、実施時の課題

別会場からの質問が届かない場合がある

これは発表者のいる会場側でも同時に質問が上がった場合に発生します。おそらく音声が被って聞こえなかったのだと思われます。 会場間で情報をシーケンシャルに制御できないことに起因するものであり、例えば各会場の司会が明示的に会場を指定した質問の募集をする等、質疑応答の進め方を事前に相談しておくと良さそうです。

発表者は、別会場のリアクションを知ることができない

発表者のPCはスライドモードで全画面が占められていることから、他の会場の映像を見ることができません。そのため渾身のネタがスベったのか笑いが発生したのか、今の説明が聴衆を置いてけぼりにしていないかなどの反応を知るためには自分の会場の聴衆をサンプルとする必要があります。 実際の発表中は、前の方の十数名ぐらいしか見ていないので問題はないのですが、例えば別会場の笑い声などをうまく伝えられるようにしたり、発表者が見ることができる別のディスプレイに他の会場の様子が映されていたりするのも良いかもしれません(嗚呼、どんどん設備が豪華になっていく…)

反対に、会場間の聴衆側の雰囲気の共有については他のツールに移譲してしまって良いと思っています。 具体的にはTwitterのハッシュタグを共有するなどして実況ツイートが流れれば十分、会場間の一体感が感じられました。

Google Hangouts MeetとKeynoteの画面共有で発表者ディスプレイモードが利用できない

これはリモート勉強会というよりはGoogle Hangouts MeetとKeynoteの使い方の問題ですが、発表者ディスプレイモード(発表者の手元の表示が次のスライドや経過時間がわかるようになる)が利用できなかったため発表が若干やりにくかったです。 ウィンドウの共有からKeynoteを選択し、スライドを開始すると手元のディスプレイが真っ黒になるため、画面全体を共有してスライドを開始していますが、手元のディスプレイが発表者ディスプレイモード(次のスライドや経過時間がわかる表示)ではなく参加者が見ているのと同じ状態になってしまいます。

ただ、ここに関しては、外部モニターを接続し、外部モニターを画面共有先にすることで回避が可能と検証していただいていたので次回試してみようと思います。

5. なぜ勉強会会場を接合点としたか

リモート会議サービスへ参加すればよい環境となっていることから、勉強会会場に行かずとも家やオフィスから見たいという声も聞くようになりました。 これについては、極端な場合、接合点を参加者とするような、会場という概念がない勉強会は開催はできても継続はできないのではないかなと考えます。 ただ、最終的には勉強会ごとのポリシーに沿うでしょうし、絶対的な正解はないことから、ここでは個人としての考えを述べます。

サービスの制限

単純にサービスの制限として同時接続数が定められている(Google Hangouts Meetだと50ぐらい)ために接続を会場と発表者に限定したい。 ですので制限が緩和されたり制限未満の参加者であれば勉強会開催はもちろん可能です。

発表者のモチベーション

本エントリで述べる形式の勉強会で発表する方のモチベーションはプレゼンス向上や議論による提案のレベルアップ、便利情報の共有によるコミュニティへの還元など様々ですが、一定の人数を相手に一定の時間、注目をしてもらうために少なからず時間を投資してクオリティを確保した資料と発表準備を行なっています。

これに応じるようなある種の熱量は、たとえ数が揃っていたとしても個人の集まりでは発生させるのは難しいと思っていて、やはり目的や時間を共有しているような集団とこれをオーガナイズする人がいてこそだと思います。 この熱量を相互に期待することで会が成り立ち、活発な議論やスパイク的な反応が生まれる、これを満たす集団が各会場の勉強会にあたると考えています。 また、家やオフィスだとどうしても”ながら見”になりますし、発表者にとっても自分の前に実際に誰もいない状態での発表というのは(発表に慣れた人であるほど)逆にやりにくいものです。 これらの理由から、どうしても最寄りの会場への移動が困難である等の個人接続は許容した上で、勉強会会場単位での接続が良いのではないかと考えます。

そもそも集うことが目的でもある

特にFukuoka.goは、単純に集まって興味関心を同じくする人と知的好奇心をくすぐる話題を肴に同じ時間を過ごしたいというのが源流としてあり、普段はバラバラに活動している人たちが集まってワイワイするのが目的だったりします。

コミュニティは実在するものではなく活動が継続していることでのみ存在を維持できると思っており、主催側自体も楽しめること、新しい参加者や知識、提案が吹き込まれることを常時望んでいます。 そのため、志を同じくする熱量のある集団として別地域の勉強会と知り合えることはお互いに利がありますし、単純に嬉しいものです。


いくつかの理由を述べましたが、上述の通り何が正解というわけではなく、今後、色々試してみてより楽しんで楽にできるやり方を探したいところです。

まとめ

福岡在住の技術者として、リモート勉強会を通して、距離の制約から解放され、興味ある分野の勉強会に参加して発表をリアルタイムに聞けること、さらに自分のノウハウや提案をより多くの人に聞いてもらえる機会が広がったことを嬉しく思います。 また、勉強会の主催者としても、知らないうちに出来上がるコミュニティの枠に対して新規の参加者同士が交流しやすくなることによって、停滞感が払拭され結果的に各勉強会自身の活発化が促されるであろう利点にも注目しています。 今後もリモート勉強会を通して、地域の勉強会が等価に柔軟に接続し合うことで一層のコミュニティ発展に繋がることを願っています。

OSS Gateにサポーターとして参加した(東京・福岡)

OSS Gate Fukuokaにサポーターとして参加した.サポーターとしての二度目の参加で前回はOSS Gate東京ワークショップ2018-10-27 だった.

OSS Gateは「OSSの開発に参加する」を実際に体験するワークショップ である. 元々,OSS開発に関するノウハウなどを共有するためのOSS道場という個別相談会を社内でやっており,その関連でサポーター役を紹介をしてもらったという経緯がある. OSS道場が自分のOSSを作ることを通してエンジニアリングに必要な各種スキルを高める目的としているのに対して,OSS GateはOSS世界への参加の敷居を下げるために実際に既存のOSSプロジェクトに参加貢献するところを一緒にやっていきましょうというものになっている.

カリキュラム自体は非常に洗練されており,OSS未経験者であるビギナーはもちろんのこと,手伝う側のサポーターもOSS Gate自体が初めてでもいきなり参加できるようになっている. 具体的な内容はこちらを見ていただくとして,対象のOSSを見つけて実際にIssueやPullRequestを送るまで一連の流れを経験できる.

前回の東京開催の後に福岡開催できればなあと考えていたところ,同僚のうづらさんなどがうまい事引っ張ってきてくれたので渡りに船だった.福岡での開催も和気あいあいと良い雰囲気で進んだと思う.

まとめ

うづらさんも言っていたが,福岡でOSS Gateに参加してくれた人は,次にぜひFukuoka.rbやFukuoka.goなどのコミュニティに参加してほしい. どのコミュニティも技術を楽しんでいるところばかりで,OSSへの参加や自分のOSSを作ろうというモチベーションにきっと繋がると思う.

ちなみにFukuoka.go#13は2月ですよ!

Go Conference 2018 Autumnで発表してきた(3年ぶり3回目)

11/25にGo Conference 2018 Autumnというイベントでフィードバック制御によるGoroutine起動数の最適化を発表してきました.

Goでの開発時に常に悩んでいたGoroutine起動数に関してフィードバック制御という切り口でKaburayaアーキテクチャと題して解決策を検討したものです. 直前にWSA研向けに研究として再定義したことでGoroutineにこだわらない,より汎用的な問題に対するアプローチとして検討し直すことができ,まだ最適解は模索中ですが,面白いと思っていただける発表ができたのではと考えています.

歴史ある制御工学という分野の手法を用いることで蓄積されたノウハウを活用できると考えていましたが,発表後に早速有意義なアドバイスなど頂くことができ,今後の精度,速度向上並びに汎用化に向けて面白くなってきそうです.

ちなみに開発にあたってGoランタイムを調べていた時の資料も#goconハッシュタグで放流したところ,こちらも好評でしたので改めて置いておきます.

発表を終えて

GoConでの登壇は今回で3回目となりました.ここ数年,自分のキャリアや興味範囲が広がっていく中でも,Go言語はずっと相棒として付き合ってくれる言語でしたし,Go言語を中心に色々な付き合いができていると感じています. そしてその契機となったGoConと,これを継続して開催してくれている運営の方々に本当に感謝いたします.

主催するFukuoka.goでも微力ながらコミュニティの活発化に繋がるよう引き続き”楽しみながら“やっていきたいと思います.

次は海外カンファレンスで登壇するぞう.

Gopherくん

今回で登壇特典のGopherくん全色コンプリート!!

gophers

過去の発表

Kaburaya: CPU負荷に応じて継続的に上限値を最適化する動的セマフォ

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

はじめに

マルチコア時代において,単一のマシンで処理性能を最大化するため処理の並行化が行われる. ノンブロッキングな処理方式の採用によってCPUを効率的に使用する場合には最適な並行数はCPUコア数と等しくなる. しかしノンブロッキングを実現するランタイム実装の限界から,もしくはノンブロッキングを採用していない場合のような,全体的もしくは部分的にブロッキングが発生する状況においては,最適な並行数の決定は依然として開発者の経験と地道なチューニングに依存している. このような最適な並行数を求める例としてnginx, unicornのworker_processes,Sidekiqのconcurrency,Goroutineの起動数などが挙げられる. これらは、実行される処理の負荷や特性がアプリケーションごとに異なるため実行される処理の特性とランタイムやスケジューリングの特性を考慮したチューニングが必要になる. このような複雑な系に対する普遍的なチューニング手法の発見は困難であることから,これらをブラックボックスとして扱い汎用的に調整できる手法が求められる.

三宅らは仮想サーバの予測的オートスケーリングにおいて,アプリケーションの処理内容ではなく運用経験から得られたサーバ単位のスループットを指標として,これを予測するモデルによってサーバ台数調整機能を実現した. また,「全自動パラメータチューニングさん」ではメトリクスを一点に絞りスループットが最大化する値を探索的に求める. これらの手法は指標を限定しても充分な成果が得られることを示した.一方でその求め方は予測的または探索的であり,Webサーバープロセスのように比較的長期稼働する場合に適用可能である. しかしながらCLIのような短期稼働かつ性能が求められるようなプロセスにおいては予測や探索は利用できない. これらの利用用途に対応するため,指標の限定に加え,反応的かつ誤差が少なく指標へ追従する手法が必要である.

本研究では,処理やランタイムの特性に依存せずに,マシンの負荷に応じて反応的かつ継続的に,並行数を最適化する手法を検討する. まず,最適な並行数を求めるために,最適化の手法としてフィードバック制御を用いる.指標にはノンブロッキングな処理方式がCPUを効率的に利用することに着目し,CPU使用率を採用する. 次に,並行数の制御にはセマフォを採用することで提案手法に汎用性を持たせる. 本報告では,ノンブロッキングな処理方式をランタイムとして採用するGo言語において,CPU負荷に応じて継続的に上限値を最適化する動的セマフォを実現するライブラリを開発し,これを評価する.

実装

フィードバック制御を用いてGoroutineの起動数を動的に調整する手法を実装するためには,ある時点で最適なGoroutineの起動数をフィードバック制御によって決定する仕組みと,その起動数を制約としてGoroutineの起動数を制御する仕組みが必要となる. このような並行処理の起動数を制御する仕組みには一般的にセマフォが利用される.Go言語ではセマフォとしてバッファ付きチャンネルを用いるのが定石となっている. そこで本研究では,最適なセマフォの値をフィードバック制御によって動的に変更可能な仕組みを構築した.なおこの実装はOSSのkaburayaとして公開している.

制御器

本研究では,ある時点で最適なGoroutineの起動数をフィードバック制御によって決定する仕組みを制御器と呼ぶ. 今回,制御器の設計についてはGoroutine起動数が制御可能な入力となる.これによって対象のスループットを最大化するのが目的である.しかしながら実行される処理の負荷や特性が異なっても共通に採用できる固定値のスループット値は事前に求めることはできないため別の指標を用いる必要がある. 本研究ではいくつかの制御器の評価を通して効果的な制御器を求める. 以降,Go言語ランタイムがI/Oブロッキングな処理についてもGoroutineの切り替えにより、その負荷をCPU側に移動させることから,CPU負荷が安定になることが一つの上限とみなせると仮定していくつかの制御器を設計する.

  1. 初期値からワーカー数を変えないFixController (比較用)
  2. CPU使用率100%を目標値とし,不足した場合は workerを1ずつ増加させる SimpleController
  3. CPU使用率100%を目標とし,目標との差分のK倍を加える PController(比例制御)
  4. 3.のCPU使用率の目標値を90%としたもの
  5. 直近3観測点の平均を目標値として3観測ごとにPControllerの目標値を変化させるDynamicController
  6. 一定期間のCPU使用率の標準偏差をとってそれが一定の値以下だったら安定したとみなして,workerを減らしていくStabilityController
  7. CPU使用率ではなくてCPU使用率の変化率を元に制御するRateController
  8. 5.のDynamicControllerを元に定期ではなく大きな変動ごとに目標値を見直す方式
  9. 8.のDynamicControllerを元に定常時の不要なworkerを削減する方式
  10. 9.のDynamicControllerを元に変動の精度と速度を向上させるために積分微分制御を導入する方式

セマフォ

本研究では,制御器によって決定された起動数を制約としてGoroutineの起動数を制御する仕組みをセマフォと呼ぶ. 今回のセマフォの要件としてはセマフォの上限値が動的に変更可能であること,そして通常のセマフォと同様にP操作において値が負になる場合に実行がブロックされる.またこれらの値の変更がアトミックに行われる必要がある.

これらはGo言語では二つのチャンネルを組み合わせることで実現可能である.すなわち,それぞれのチャンネルからの入力と出力でセマフォの値を更新し,必要に応じて内部でチャンネルへの操作の有効無効を切り替えることで結果的に利用者側に対するブロック処理を実現する.

評価

本研究では,設計した制御器の出力する起動数が最適であることを検証する.ここで最適であるとは,処理対象のタスク全体を,最低限の,のべ起動数で,最短の時間で処理できる起動数を指す. 評価には,汎用性と再現可能性を高めるため,以下の機能を持つシミュレーターを用いる.

  • シミュレータは実時間ではなく,単位時間をステップとみなす
  • JobはWorkloadを持ち,ステップごとのCPU利用率を定義する
  • Workloadが0のステップはブロッキング処理を表現する
  • シミュレータはステップごとに任意の数のジョブを投入する
  • シミュレータはステップごとに起動可能なワーカー数を制御器から取得する
  • ワーカーはシミュレータで利用可能なCPU利用率までジョブの該当ステップのWorkloadを消費する
  • 消費できなかったWorkloadは次回のステップに回される
  • Workloadが0のステップはCPU資源を消費しないため無条件にステップを進める

  • 現状はスイッチングコストがシミュレータに反映できていない.

JobにはCPUビジーとなる処理,多くのシステムコールが発生する処理,ネットワークのような長期間のブロッキングが発生する処理などを再現したものを投入する.

設計した制御器に対する主な評価結果は以下のとおり

シミュレーション1

初期値からワーカー数を変えないFixControllerによって固定値での最適なワーカー数を求めた.今回のシミュレーションではworker:7 ぐらいが最適と考えられる.

result

シミュレーション2

CPU使用率100%を目標値とし,不足した場合はworkerを1ずつ増加させるSimpleControllerでは,ジョブが多く投入される初期段階においてワーカー数の増加が追いつかないことからジョブ全体の処理がシミュレーション1と比較して長くなってしまっている.

result

シミュレーション4

CPU上限を目標値とした場合に制御器の出力が負にならないため,ワーカー数を削減することができない.そこでCPU使用率90%を目標とした.CPU上限に達した場合に不要なワーカー数を削減する一方で,目標値が固定のため,ジョブが完了し,CPU使用率が低下した場合にも反応してしまった.

result

シミュレーション5

目標値が固定であることからジョブ完了後にワーカー数を増加し続けてしまう問題に対応するためCPU使用率の目標値自体を変動させることとする. 本シミュレーションでは,CPU使用率が均衡する時点をワーカー数の上限であると仮定し,直近3観測点の平均を目標値として3観測ごとに制御器の目標値を変化させるDynamicControllerを実装評価した.

result

シミュレーション9

CPU使用率やジョブ実行状況にできるだけ速く追従するため,一定間隔ごとに目標値を見直すのではなく,CPU使用率の変動があった時点で目標値を変更する. 大きな増減を契機に調整していく仕組みになったことで,CPU安定時に積極的にワーカーを削減することができるようになった

以下では目標値の変動を赤でプロットしている.

result

シミュレーション11

頻繁に変更される目標値に高速かつ誤差が少なく適応していくため古典的制御手法であるPID制御を導入した. 調整の結果,本シミュレーションではPID制御のゲインとしてKp: 0.1, Ki: 0.5, Kd: 0.5が有効であった.

result

result

その他のシミュレーション

検討段階の各シミュレーション結果についてはこちら以降のコメント欄を参照のこと. 制御器の実装の番号とシミュレーション番号が同じにしている.

また,実環境で同様のジョブを用いた評価結果について今回は間に合わず未評価である.

まとめ

本研究では,処理やランタイムの特性に依存せずに,マシンの負荷に応じて反応的かつ継続的に,並行数を最適化する手法として,CPU負荷に応じて継続的に上限値を最適化する動的セマフォを提案した. また,シミュレーション環境においてではあるが,ノンブロッキングな処理方式を前提とする場合に有効なCPU使用率の目標値を負荷情報に応じて変動させる制御器として設計することができた. 本方式はCPU使用率とセマフォというランタイムや実装に依存しない方式を採用しているため,並行数を求めなければならない様々な場面に適用可能であると考える. 今後の課題として,実環境での評価としてGo言語のGoroutineの起動数に対する評価が必要である. また,制御器のパラメタ設計も課題として挙げられるが,フィードバック制御という歴史ある分野の蓄積を有効的に活用することで解決したい.

発表スライド

発表を終えて

第三回のWSA研も様々な観点からの提案と活発な議論が交わされる有意義な場であったと思う. 特にrrreeeyyyさんのA survey of anomaly detection methodologies for web systemは業務で得た知識をサーベイ論文と組み合わせて再体系化していく非常に興味深い試みで,サービス運用者が参考にしていくべき取り組みだと思えた. 自分自身の研究発表では,個人的な開発時の課題であるGoroutine起動数のチューニングという課題から,研究を意識して問いを抽象化することで,実装に囚われない多角的な解決策を講じることができた点が良かったと思う.質疑では本手法が活きる場面を整理できていなかったことに気づけたことでもう一段先に進めた. 自身のアイディアや実装など狭い範囲から視点を広げるのは難しいことではあるが,こうして研究会を契機に継続的に訓練していくことで少しづつでも前に進んでいると思えるのはとても嬉しい.

理性の人

思えばこの一年半は自分の感情に振り回された期間だった. エンジニアとして新しい道が見えながらも,そこに近づけない不甲斐なさと焦り. 自己肯定感が著しく下がったために価値基準がだんだんと外部へ移り,余計に道を見失う. 局所的には努力しているけれども,不安解消や短期的な承認に囚われて殻にこもりがちになる. 愚痴や相談で一時的に心は軽くなれどもいつのまにか焦りが高まる.

いい加減,自分との向き合い方について考えなければならない時期だと思った.


幸いにもここ最近,何人かの自分の尊敬する人とまとまった時間話す機会があり,自分との考え方の違いなどを意識して比較してみた. 元から,皆一様に論理的で理路整然と自他の意見の要点や本質を掴んだ議論ができる能力の面で見習いたいと感じていたのだが, 最も自分と違っていたのは,客観性をもって自分がなすべきことを検討し続け,そこに向けて邁進している点だと思えた.

すなわち,彼らは理性的であった. 理性とは,手元の辞書によると「感情に動かされたりしないで,論理的に考えをまとめたり物事を判断したりする頭の働き」とある.

自分も感情に振り回されないようになれば,先に進めるのかと思いつつも,思考から感情を分離することはとても難しいことではないかと思えた. なぜなら自分は極度の負けず嫌いである.自分にも他人にも負けたくないというのが心根にある.勝っていたり承認されている状態というのは素直に嬉しいし,この動機付けが今まで自分を成長させてきたとさえ思っている. しかしながら,この主観的で感情的な動機は上手くいくうちは良いが,失敗すると簡単に歪んでしまうというのもまた事実である. 誰かに勝つため,負けないため,舐められないため,価値を認めてもらうため.往往にしてなすべきことではないものを目指し始める.さらには引け目があるから,それらを貫き通すことも難しくなる.

ただ,このようなことを悶々と考えるうち,自分の中で感情的である状態と理性的である状態というのを区別し現状を俯瞰できるようになってきた. ここで,理性的な人は,感情を抑え込むのではなく,感情とうまく付き合い,感情に動かされないための方法論をそれぞれ持っているのではないかと考えた. 自分の場合,承認欲求は強く自己と結びついてしまっていてこれを無視することはできない.であれば二つの状態があることを認識し,これを行き来するための方法論を見つけることで理性的に振る舞えるようになるのではないか.

理性の人でありたい.

  • 理性の人は,感情を抑え込むのではなく感情に動かされないための方法論を持つ.
  • 理性の人は,論理的になすべきことを定める.
  • 理性の人は,なすべきことを解決するため,己を高める.
  • 理性の人は,なすべきことを解決するため,周りと協力する.

何も感情を無くそうというのではない.自分の性質のため視野が狭くなりがちなことを認めて,目的を客観的に定めたのち,楽しい手段を見つけたい.行動方針における優先順位を明確にしただけである. 結果的に相対的な価値観の世界からも脱却し,より大きなことを成せるのではないかと思う. もちろん,理性の人になるためには多くの努力が必要であり,今後も継続して努力していく.技術力も思考力に対してもやるべきことはたくさんある.ただ,局所的であろうが今までの努力も無駄ではない.うまく活かして一気に花開きたい.

Archives