TerraformのStateとは、Terraformで管理しているリソースの状態をJSONで記述したものであり、ファイルとして永続化されている。
Stateが何のためにあるのか、についてはオフィシャルな解説があるので詳しく説明はしないが、Stateには主に以下の目的がある。
このエントリでは、Performanceに着目する。
Terraformは、plan/applyを実行する際に、どのような変更を行う必要があるのかを決定するために、リソースの最新の状態を知る必要がある。 デフォルトの動作では、plan/applyを実行するたびに、すべてのリソースの最新の状態を取得しにいく。
これがState Refreshである。
State Refreshは、例えばAWS上のリソースを管理している場合は、リソースひとつひとつに対してAWSのAPIにリクエストを投げ、情報を取得する。また、リソースの種類によっては、ひとつのリソースに対して複数のAPIリクエストを投げることもある。
そのため、Terraformで管理しているリソースの数に応じてAPIリクエストの回数が増え、Refreshにかかる時間が増える。APIにはRate Limitもあるので、並列にリクエストを投げて高速化するのも限界がある。
管理しているリソースの数が少なければ、Refreshにかかる時間は問題にならないが、多い場合にはちょっとした変更を確認したいだけの場合でも、State Refreshで数分待たされることになる。
Terraformコードをサブディレクトリに分けStateを分割することで、State Refreshを高速にする、という手法が一般的に使われている。Stateの分割によりRefreshの高速化は見込めるが、細分化しすぎると運用管理が煩雑になる。
また、オフィシャルな解説では、リソースの数が多い場合は、-refresh=false
や-target
オプションを利用することで、Refreshに時間がかかるのを回避する、といった記述がある。
-refresh=false
オプションの場合には、ファイルに永続化されたStateを正とみなし、APIリクエストを投げて最新の情報を取得するようなことはしない。また、-target
オプションでは、指定したリソース(と依存関係のあるリソース)のみAPIリクエストを投げて最新の情報を取得するが、それ以外のリソースについては、ファイルに永続化されたStateを正とみなす。
しかし、-refresh=false
は、Terraform外でリソースに変更があった場合はそれを検知できない。また、-target
オプションはRefresh対象となるリソースをいちいち指定しないといけない上に、指定外のリソースについては、Terraform外で変更があっても検知できない。
そこで、State Refresh高速化のための手法として、以下の手法について考えてみる。
それぞれについて掘りさげる。
ファイルに永続化されているStateが常に最新の状態になっていれば、-refresh=false
オプションでRefreshをスキップしても、最新の状態が得られる。これにより、terraform plan/applyのState Refreshにかかる時間を0にすることができる。
これを実現する方法のひとつとして、以下のようなやり方が考えられる。
AWSのリソースをTerraformで管理している、という前提の元では、具体的には以下のような実装が考えられる。
flowchart LR
terraform[Lambda Function]
event[CloudWatch Events]
s3[S3 Bucket]
event -- 1 --> terraform
terraform -- 2 --> s3
terraform refresh -target
でStateを更新して保存コンセプト実装として、tfrefreshというものをつくってみた。
詳細は省くが、様々な面で実装や運用がかなり面倒ということがわかり、この手法はあまり実用的ではない、という判断に至った。
その1のやり方は、常にリソース変更イベントを監視し、リアルタイムに最新の情報を永続化Stateに反映する、という仕組みを維持管理する必要があり、運用の手間がかかる。
Terraformユーザから見れば、永続化Stateは常にリアルタイムに最新の状態を反映している必要はなく、Terraform実行時に最新の状態を反映していれば良い。そこで、AWSのリソースをTerraformで管理している、という前提で、次のような実装を考える。
flowchart LR
cloudtrail[CloudTrail]
s3[S3 Bucket]
program[State Update Program]
cloudtrail -- 1 --> program
program -- 2 --> s3
terraform refresh -target
でStateを更新して保存。その後terraform plan/applyが実行される。このようにすると、Terraform実行前に、永続化Stateが最新の状態に更新されるため、-refresh=false
オプションを利用して、State Refreshにかかる時間を0にすることができる。
こちらも詳細は省くが、そもそも永続化されたStateが最新更新日時を持っていないなど、Terraformの仕様上実装が困難ということがわかった。また、実装できたとしても、Terraform実行の直前にログからRefresh対象を判別し永続化Stateを更新するため、状況によってはかえって時間がかかる可能性もある。
先に挙げた、予め永続化Stateに最新の情報を反映しておくのとは別なやり方として、Terraform実行時にRefresh対象となるリソースを絞るやり方を考える。
これはオフィシャルな解説にある-refresh=false
や-target
オプションを利用した回避方法そのものであるが、オプションの指定を人が判断して行うのではなく、プログラムが判断する。
Refresh対象となるリソースをどのように判別するかであるが、ここでは、Terraformコードはバージョン管理システムで管理されており、ベースブランチのTerraformコードは常にapplyされた状態である、という前提の元、ベースブランチ上のファイルとカレントディレクトリ上のファイルを比較し、差分のあるリソースを抽出してRefresh対象とする。
これを行うためのツールとして、tfdiffというツールを実装してみた。tfdiffは、ベースブランチ上のファイルとカレントディレクトリ上のファイルを比較し、リソースに差分がない場合には-refresh=false
という文字列を出力、差分がある場合には、該当リソースすべてについて-target resource_name
という文字列を出力する。
tfdiffはterraform plan $(tfdiff)
といった形で、terraformコマンドと組み合わせて利用する。
たとえば、tfdiffがリソースに差分がないと判断すれば、terraform plan -refresh=false
が実行されるし、aws_s3_bucket.foo
とaws_iam_user.bar
に差分があると判断すれば、terraform plan -target aws_s3_bucket.foo -target aws_iam_user.bar
が実行される。
これにより、Refresh対象となるリソースが必要なものだけに絞り込まれるので、Refresh時間を短縮することができる。
現在のtfdiffは250行ほどの雑なコードで、不十分なところも色々あるが、実装の労力に対して得られる効果は、先の2つの手法よりも大きく、利用のための敷居も低い。
ただしこのやり方では、差分のあるリソース、すなわち変更対象であるリソース(と依存関係にあるリソース)の情報は最新のものが得られるが、それ以外のリソースの情報は古いままである可能性が捨てきれない。冒頭で述べた、「Terraformは、plan/applyを実行する際に、どのような変更を行う必要があるのかを決定するために、リソースの最新の状態を知る必要がある。」という目的のためには十分であるが、Terraform以外のツール(ecspressoやlambrollなど)からStateを参照する際には、古い情報を参照してしまう可能性がある。
最近仕事ではTerraformを触っている時間が一番多いので、研究もこの辺りのツールに関連する技術を対象とした方が良いのでは、と考えた。研究を行うためには、類似ツールの比較が必要だし、比較のためには、サンプルコード程度のものではなく、実際の環境に近い状態を再現できるコードが必要、というのが移植のモチベーションになっている。
Deployment on Amazon EC/2 Container ServiceにAmazon ECSへのデプロイ手順が載っているが、肝心のCloudFormation Templateは、元リポジトリではDeplicated扱いで削除されている。
なので、markfink-splunk/sock-shop: Deployments of the Weaveworks Sock Shop application instrumented with SignalFx.にあるファイル(ecs-fargate/cfn-stack-app-only.yaml)を移植元コードとして使うことにした。
個人用に使っている検証用AWSアカウント、惰性で使っていてぐちゃぐちゃになってきたので、いったん不要なリソースを全削除して、AWS Organizationsでマルチアカウント化、AWS Single Sign-Onで各アカウントにSSOできるようにした。
アカウント管理用のTerraformコード、最初はprivateにしていたけど、別に見えてまずい情報もないな、と思ったのでpublicにした。
これにより、CloudFormation、Terraform、Pulumiそれぞれの検証環境をアカウントごと分離できるようにした。
まずは大元となるCloudFormation Templateがデプロイできるものになっていないと話にならないので、ここから着手。元ファイルのままでは動かなかったり、そのままでは不便なところなどあったので、微修正している。差分は以下の通り。
CloudFormation Templateがデプロイできたところで、Terraformへの移植を行った。移植はおおまかには以下のような手順で行った。
上記の作業を80ほどあるリソース全てに対して行った。
Terraformerはいまいち使い勝手が悪いし、ひとつひとつどのようなリソースがあるか確認しておいた方が、後々捗りそうなので、人力で移植した。
先日行われたHashiTalks: 日本での、Quipperの鈴木さんのプレゼンで知ったtfmigratorを使えば、Terraformerのいまいちさを補えたっぽいので、今度機会があれば使ってみたい。
Terraformerがどういまいち使い勝手が悪いのか、とか、tfmigratorの使い方なんかは、鈴木さんのブログエントリに詳しく書いてあるので、興味ある方はこちらからどうぞ。
移植の最終確認として、Terraform用アカウントにapplyしたリソースをいったんdestroyして、最初から全リソースのapplyを行った。
が、上記手順4で「差分がなくなるよう必須以外のArgumentsを記述」とあるが、planで差分がなくなっても、別アカウントにapplyすると、明示してないArgumentが原因でうまくapplyできないリソースがあったので、その辺りの修正を行った。
Pulumiへの移植も、Terraformへの移植と同様に、CloudFormation用アカウント上のリソースをひとつひとつインポートしながら進めていった。
tf2pulumiやcf2pulumiといったツールもオフィシャルに提供されているけど、自分がわかりやすいようにコードやファイルを分割したかったので、これらのツールは使わなかった。
PulumiはTypeScript、JavaScript、Python、Go、C#から記述言語が選べるが、この中で一番慣れているGoで記述を行った。
Pulumiのリソースインポートは、Terraformと違いコードの生成まで行ってくれる。
たとえば、
$ pulumi import aws:cloudwatch/logGroup:LogGroup \
sock_shop \
sock-shop
といったコマンドでCloudWatch Logs log groupをインポートすると、以下のようなコードを吐いてくれる。
ただ、pulumi import
ではエラーになってうまくインポートできない場合もあり、そういう場合は、先に以下の様なコードを書いてから、pulumi up
を実行してインポートした。最後のpulumi.Import()
がポイント。
また、希にpulumi import
が吐くコードが間違っていることもあって、そういう場合は手で修正を行った。
Pulumi、サンプルコード程度しか触ったことがなかったけど、今回の移植作業でだいぶ把握できた気がする。
最初の方でもリンクを張っているけど、移植したコードはここに置いてあります。
]]>なんやかんやあって、今年から京都大学大学院情報学研究科博士後期課程に進むことになった。
京都大学大学院情報学研究科博士後期課程の入試、無事合格しました。4月から2年ぶりに学生に戻ります。
— mizzy (@gosukenator) February 10, 2021
これに関しては、書くと長くなるので、別エントリで書くかもしれないし、書かないかもしれない。需要がありそうなら書きます。
仕事しながら大学に通っていた時のWEB+DB PRESSのインタビュー記事に対して、当時まだ面識がなかったまつもとりーさんからこのようなコメントをいただいていた。
このまま博士にもいかれるのだろうか / “第4回 宮下剛輔(mizzy)~はたらきながら大学に通う:シューカツ女子ともよの会社訪問記―知りたい!あの人のはたらきかた|gihyo.jp … 技術評論社” http://t.co/P2DglRWD4m
— Ryosuke Matsumoto / まつもとりー (@matsumotory) April 24, 2013
まさか、その後まつもとりーさんと面識を持つことになり、まつもとりーさんの導きで博士後期課程に進学することになるとは、この当時はまったく思ってもみなかった。
現在お仕事をいただいてるのは、リクルートマーケティングパートナーズ さん、タレンティオ さん、アカツキ さん、ホンダ さん、さくらインターネット研究所 さんの5社で 昨年のエントリ で書いたのと変わらず。
仕事内容も特に大きな変化はない。
元々リモートワークだったので、普段の仕事にはそれほど影響はない。ただ、ミーティングは直接顔を合わせて行っていたのが、すべてリモートで行うようになったので、外出の機会は減った。
学会、研究会、技術カンファレンスなどもほぼすべてオンラインになった。他の家族もいる家の中で、長時間/数日間にわたって開催されるカンファレンスに集中して参加するのは難しいので、そういう場合はホテルに缶詰になって参加してる。
ホテルに缶詰になるときは、ほぼ ヒルトン福岡シーホーク に泊まっている。
なぜわざわざ福岡まで行くのかについては、この辺 に書いたので興味のある方はどうぞ。
福岡以外だと、吉田真吾 さんにお会いするのも兼ねて、沖縄まで行ったこともある。
ホテルで仕事するの、デスクとか椅子とかインターネット回線とかが問題になるけど、ヒルトン福岡シーホーク、今まで泊まったことのあるホテルの中では一番良い。デスクの広さは部屋にもよるけど、椅子は自分が知る限り、全室SteelcaseのThinkチェア(固定アームタイプ)が配備されている。インターネット回線も有料の方(ダイヤモンド会員は無料)であれば、fast.comで100Mbpsが安定して出る。なので、福岡で一度試しに他のホテルに泊まったけど、回線が不安定だし椅子も仕事向きではなかったので、予定より早くチェックアウトしてヒルトン福岡シーホークに移動したことがある。
安定したインターネット接続と快適なワークチェアを求めて、グランドハイアットからヒルトンに移動した pic.twitter.com/a1Y15UNFOK
— mizzy (@gosukenator) February 6, 2021
海外カンファレンス、すべてオンラインになって参加しやすくなったけど、弊害もあってなかなか厳しい。
海外カンファレンス、現地開催だと強制的にそこのタイムゾーンで生活することになるけど、オンライン開催で日本にいながら参加となると、どちらのタイムゾーンにもひきずられて厳しい、ということをACM/IFIP Middleware 2020に参加して実感した。
— mizzy (@gosukenator) December 11, 2020
幸いなことに、COVID-19の影響も特になく、昨年と同じ程度の売上。国内、海外含めて、予定していたカンファレンス参加のための出張がほとんどなくなったが、その分を福岡出張にあてたので、利益も昨年とほぼ同じぐらいになった。
大学院生になるといっても、仕事も今まで通り続けながらなので、大変なことになりそうだけど、楽しみながらやれたらいいなと。
]]>マネージドなコンテナ実行環境の普及に伴い、Configuration Managementツールを利用する必要がある現場は少なくなったが、Configuration Managementツール自体の必要性はまだ失われていない。また、モバイルコンピューティングやエッジコンピューティングの普及に伴い、Configuration Managememntツール自体のあり方も今後変化していくと考えられる。
本予稿では、Configuration Managemantツールの役割を整理し、Configuration Managementツールの今後のあるべき姿を検討する。それにより導きだされた、Configuration Managementツールを3層で構成する方式を提案し、その中で中心的な役割を果たすポリシー定義用中間言語について考察する。
類する言葉してはサーバープロビジョニングという用語の方が日本語で多く見られるが、英語ではConfiguration Managementと呼ばれることが多い。
Configuration Managementとは、Burgess、Couchらによると1、「予め定義されたポリシーとガイドラインに従い、事前に決められたビジネス上の目的を達成するよう、ネットワーク接続されたマシンの振る舞いを制御するプロセスである」と述べられている。
Configuration Managementツールとは、その名の通りConfiguration Managementを行うためのソフトウェアである。
代表的なものとして、CFEngine, Puppet, Chef, SaltStack, Ansibleなどがある。特に、後発のChef, Ansible, Puppet, SaltStackをまとめてCAPSと呼ぶこともある。
Configuration Managementツールは「予め定義されたポリシーとガイドラインに従い、事前に決められたビジネス上の目的を達成するよう、ネットワーク接続されたマシンの振る舞いを制御する」ためのツールである。このことから、Configuration Managementツールには以下の2つの役割があると捉えられる。
実際、先にあげた代表的なConfiguration Managementツールは、この2つの役割を持っている。それぞれのツールの違いは、「ポリシー定義」と「振る舞いの制御」の2つに関する実装の違いとも言える。
Configuration Managementツールの役割のひとつして「ポリシーの定義」を先に挙げた。ポリシーの定義は、何からの言語を用いて行うことになる。Configuration Managementツールの文脈で言語に言及する場合、ポリシー定義用言語と実装言語が混同されることがあるので注意が必要である。
Configuration Managementツールに採用されているポリシー定義用言語は、大別すると独自言語、YAMLのような簡易言語、プログラミング言語の3つにわけられる。ポリシー定義用言語としては、YAMLが最も人気があるように見受けられる。Configuration ManagementツールではAnsibleが今でも人気があるが、YAMLを採用していることが一因と考えられる。
また、Configuration Managementツールではないが、Infrastructure as Codeに関連するツールとしては、KubernetesもYAMLを採用している。
従来のConfiguration Managementツールの利用対象者であったシステム管理者は、プログラミングを行わない人が多いため、YAMLのような簡易言語が好まれる傾向にあると思われる。
また、YAMLのような簡易言語は変数やロジックがないため、記述を簡易にできメンテナンスしやすい、といった点も好まれる一因と考えられる。(ただし、変数やロジックがない、というのは欠点でもあり、それを補う手法が同時に使われているケースもある。)
一方、クラウドの普及により、システム管理者だけではなくアプリケーション開発者もサーバーインフラを触るようになった。このような人達は、簡易言語や独自言語よりも、慣れ親しんでいるプログラミング言語を好む傾向にある。
いずれにせよ、どの言語がポリシー定義用言語として最適なのかは、利用する人や組織が置かれている環境、利用者のスキル、好み等に依存するため、一概に決めることはできない。
Configuration Managementツールのもうひとつの役割である「振る舞いの制御」を行う方法も、ポリシー定義用言語同様、様々である。
例えば、ChefやPuppetはサーバー/エージェント型の構成をとっており、中央のサーバーで管理されたポリシーを各マシンに配布、適用して振る舞い制御を行う。また、サーバー/エージェント型としてだけではなく、スタンドアローンで実行することもできる。
サーバー/エージェント型は、ポリシーの配布、サーバー/エージェント間の接続や認証、マシン制御の実行方法やタイミングなどをツールに任せることができる、というメリットがある。反面、サーバープロセスやエージェントプロセスの監視をどうするか、サーバーとエージェントの初期接続時の認証情報をどのように受け渡すか、などといった点を考慮する必要がある。
一方、スタンドアローンで制御を行う場合は、常駐プロセスがないため、サーバー/エージェントのプロセス監視や接続時の認証については考える必要はない。反面、ポリシー定義コードをどのように配布し、どのようなタイミングでポリシー適用を行うのかを、自ら決める必要がある。
Ansibleはエージェントレスで、スタンドアローンで制御したり、リモートマシンに対してSSHで接続して制御したりすることもできる。これもChefやPuppetのスタンドアローン型と同様のメリット/デメリットがある。
また、モバイルデバイスやエッジデバイスの普及に伴い、多様なデバイスへの対応、転送容量削減、メモリ容量節約、実行速度の向上、自律制御といった観点から、別の制御実装が求められることも考えられる。
さらに、現在のConfiguration Managementツールは、記述されたポリシーを逐次解釈して制御を行うインタプリタ型だが、制御用コードを生成して実行するコンパイラ型の方が望ましいケースも考えられる。
このように、ポリシー定義用言語と同様、振る舞い制御の実装についても、サーバーマシンが置かれている環境や、どのように管理を行いたいか、といった前提条件によって適した制御方法が異なるため、どの振る舞い制御実装が最適かを一概に決めることはできない。
ポリシー定義用言語も振る舞い制御実装も、条件によりベストなものが異なる、という前提に立つと、様々なポリシー定義用言語や振る舞い制御実装が存在する、ということは好ましいことである。
しかし、既存のConfiguration Managementツールは、ポリシー定義言語と振る舞い制御が密結合している。そのため、用途に適したポリシー定義用言語や振る舞い制御実装を備えたツールが存在しない場合、ポリシー定義用言語部分も振る舞い制御部分も一から実装する必要がある。また、あるツールのポリシー定義用言語だけ差し替えて振る舞い制御実装のみ利用する、といったことも不可能である。
ポリシー定義用言語と振る舞い制御実装が密結合していると、部分的に再利用できないため、開発に無駄が生じる。そこで、多様なポリシー定義用言語と振る舞い制御実装に対応しつつも、開発コストを抑えるために、ポリシー定義用言語と振る舞い制御の実装を分離することを提案する。提案方式はLLVMに着想を得ている。
LLVMは以下の図のような3層モデルになっており、各種言語用フロントエンドが、その言語で書かれたコードをLLVM IRという中間言語に変換、その後LLVMが中間言語に最適化処理などを施し、最終的には各CPUアーキテクチャ用のバックエンドが、そのアーキテクチャで実行可能なバイナリコードを生成する。
LLVMの「3層モデル」「中間言語」という概念をConfiguration Managementツールに応用すると、以下の図のようになる。
Optimizer部分で何をするのか、という点については現在のところアイデアはないが、Optimizeする必要がなければ、そのままバックエンドに渡す形となる。また、右端の制御実行は、逐次実行型の場合は中間言語を解釈してそのまま実行することをイメージしているが、そうではなく制御実行コードを吐き出す、という形も考えられる。
このような形にすることで、利用者は用途に適したポリシー定義言語や振る舞い制御実装を選択できる。また、用途に合うポリシー定義言語や振る舞い制御実装が存在しない場合に、ポリシー定義用言語のみ、あるいは振る舞い制御実装のみ開発する、といったことも可能となる。
3層構造のConfiguration Managementツールにおける中間言語は、各種ポリシー定義用言語とN対1で対応するものであるので、中間言語自身もポリシー定義用言語であると言える。そのため、中間言語はポリシー定義用言語に適した性質を備えている必要がある。
ポリシー定義用言語に適した言語とは何か、についてはまだ十分考察できていないが、今のところ考えていることをリストアップする。
今後、この考察を更に深めていく予定である。これらに対する意見や、こういったアプローチで考察すると良いのでは、といった助言があればぜひ頂きたい。
]]>Serverspec:宣言的記述でサーバの設定状態をテスト可能な汎用性の高いテストフレームワークでは、従来手法を補うための要件を考察し、要件を満たすために以下の様にテストフレームワークを2つに分割する手法を提案した。
そして、提案手法に基づき実装した汎用コマンド実行フレームワークをSpecinfra、制御テストフレームワークをServerspecと名付けた。
Specinfraを利用したより優れたテストフレームワーク実装の登場や、確認業務以外の運用業務に必要なコマンド群を体系化することによるテストフレームワーク以外への応用、例えば構成管理ツールへの応用も期待し、いくつかの実装も登場したが、Specinfraは期待したほど広く利用されていない。
本予稿では、Specinfraが期待ほど利用されていない要因について考察し、解決するための手法と実装について述べる。
サーバ管理系ツールを実装する場合、多くの環境をサポートしようとすると、以下の2つ違いについて考慮し、ツール内で違いを吸収するための抽象化を行うのが一般的である。
Chef, Puppet, Ansible, Itamae(Specinfra)といった似たような目的を持つサーバ構成管理ツールは、OS/ディストリビューションや実行形式の抽象化をそれぞれ独自に実装している。
Specinfra開発の狙いは、各サーバ管理ツールで独自に実装している抽象化部分をライブラリに切り出すことによって、ツール本体の実装の手間を省き、手軽に実装できるようにすることにある。
しかし、再利用性を考慮して開発したSpecinfraはそれほど広く使われていない。
再利用性を考慮して開発したSpecinfraがそれほど広く利用されていない理由のひとつは、SpecinfraがRuby製であるため、Ruby以外のプロジェクトでは採用できない、ということである。
この課題を解決するための手法として、OS/ディストリビューションの抽象化や実行形式の抽象化を行うためのライブラリを、SpecinfraのようなRubyGemではなく、様々な言語からも利用できる共有ライブラリという形で提供する。
そのための実装をlibspecinfraと名付けた。libspecinfraはさらに以下の実装に分類される。
1は実装途中だが、現在開発を停止している。SpecinfraをRustで再実装する形で実装しているが、名前は敢えて変えずにSpecinfraとしている。
2はRuby, mruby, Python用バインディングが存在するが、こちらも現在開発は停止している。
GitHub上のlibspecinfra OrganizationにあるexamplesリポジトリにはRuby, mruby, Rustのサンプルコードがある。
PuppetやChefやServerspecについて、話題にのぼることが少なくなっている。これはコンテナが広く使われるようになり、サーバの構成管理とテストのあり方が変わってきているためである。コンテナイメージの作成は、従来のサーバプロビジョニングと比較して簡素なため、サーバ構成管理ツールの重要性が低下し、それに伴いテストの重要性も低下している。
とはいえ、従来のようなサーバプロビジョニングがなくなったわけではなく、コンテナのプロビジョニングとコンテナ実行基盤のプロビジョニング、2つのレイヤーに分離された、と考えることができる。
libspecinfraの適用領域はコンテナ実行基盤のプロビジョニングであると考えている。しかしその領域において、libspecinfraのような抽象度の高さは本当に必要なのか、コンテナ実行基盤のプロビジョニング以外にも応用できる領域がないか、等について検討する必要がある。
]]>フリーランス情報、表に色々出てくるのはとても良いんだけど、本当に人によって様々なので、色々な情報見比べた方が良い、と思ったので、リンク集的なものをつくってる。 https://t.co/GJ0HdI4LEC
— Gosuke Miyashita (mizzy) (@gosukenator) June 6, 2019
放置してアップデートしてないなこれ…
昨年の振り返りエントリ からの変更点としては、トレタ さんとは契約終了となった。2年間ありがとうございました。
リクルートマーケティングパートナーズ さん、タレンティオ さん、アカツキ さん、某社さん、さくらインターネット研究所 さん、の5社の仕事は現在も継続中。
「某社」さん、昨年の時点では名前を出すのはNGなので伏せていたけど、今年は出して良い、むしろ積極的に出して欲しい、と言われたので明かすと、ホンダエンジニアリング さんです。
現在、ホンダエンジニアリングさんとお仕事していて、第4世代LETというシステムを開発するお手伝いをしてます。AWSチョットデキル人とフロントエンドチョットデキル人探してるので、興味ある方、お声がけください。社員でもフリーランスでも。
— Gosuke Miyashita (mizzy) (@gosukenator) September 26, 2019
AWSやフロントエンドに限らず、良い人がいればいつでも是非、という感じなので、興味ある方はご連絡ください。
仕事絡みのアウトプットとしては、最近 bqnotify という、BigQueryにクエリを投げて結果をSlackに通知するシンプルなツールを、アカツキさんの仕事でつくってます。
また、さくらインターネット研究所さんの仕事として書いた Serverspec 論文 が情報処理学会論文誌ジャーナルに採録されました。
仕事面での大きな変化は、さくらインターネット研究所さんの仕事絡みで出張が増えたこと。フリーになってから5年ぐらいはほとんど出張がなく、年に1回あるかないか、ぐらいだったのが、この1年で福岡、石狩、松江、大阪、京都、ポートランド、デービス、ブリュッセルに行っている。特に福岡は5,6回行っている。福岡に行くことが多いのは、さくらインターネットさんのオフィスが福岡にあるのと、研究所に誘ってくださった @matsumotory さんがいらっしゃるからなんだけど、考えてみるとブリュッセル以外は全部、まつもとりーさんと現地でお会いしたり、一緒に行ったりしている。
ただ、COVID-19の影響で、3月は 第48回IOT研究発表会 で名古屋、情報処理学会第82回全国大会 で金沢に行く予定だったのが、どちらもオンライン開催になったり、7月にマドリードで行われる予定だった COMPSAC 2020 もオンライン開催になったりで、今後しばらく出張はなさそう。
海外出張の機会が増えそうだからとアメックスプラチナつくったらこの有様。
— Gosuke Miyashita (mizzy) (@gosukenator) March 31, 2020
一昨年と比較すると、昨年は一緒にお仕事する会社が増えたので、その分売上も増えた。出張が増えたのと、時間を有効活用するためにタクシーやUberを利用することが増えたので、売上が増えた分は旅費交通費にほとんど回っているような感じ。
今年は一社減ったけど、浮いた時間分、ホンダエンジニアリングさんの仕事時間を増やしたので、今のところ昨年と同じぐらいの売上になる見通し。
具体的な金額については、個人法人含めて hXXsyotoku.pdfを公開する|mizzy|note という有料noteに書いている。法人の売上高はざっくりした金額しか書いてないけど。
今の自分の肩書きは「フリーのソフトウェアエンジニア兼研究者」だと思っているけど、ソフトウェアエンジニアとしての実績と比較して、研究者としての実績は圧倒的に足りない。なので、研究者としての実績を積み上げていきたい。
世の中のフリーランス云々の話、フリーランス=個人事業主派と、フリーランス=働き方の一形態(個人か法人かは問わない)派にざっくり2分されていて、税金や社会保険の話になると、どちらの立場をとるかによって話が違ってかみ合わないのでややこしい。
— Gosuke Miyashita (mizzy) (@gosukenator) September 16, 2018自分は後者の、働き方による区分派。個人事業主か法人かは、税制上の区分であって、働き方とは関係ないので。
— Gosuke Miyashita (mizzy) (@gosukenator) September 16, 2018
というわけで、自分は法人化してるフリーランスだと認識している。
昨年の振り返りエントリ で書いた、リクルートマーケティングパートナーズ、タレンティオ、トレタ、アカツキ の4社の仕事は現在も継続中で、今年から新たに某社と さくらインターネット研究所 の仕事もしている。なので、現在は6社と契約していることになる。
「Openness is our driver for excellence」という言葉を YAPC::Asia Tokyo 2012 クロージングキーノート や オープンさは私のキャリアの原動力 ─ SIer、Web系、フリーランスという変遷で実感した「オープンにすること」の大切さ - GeekOutコラム といったコラムなんかで紹介しているが、この言葉は自分の行動原理を構成するとても重要なパーツのひとつ。なので、フリーランスとしての仕事でやったことも、できる限りオープンにするようにしていて、会社の技術ブログに記事を書かせてもらったり、GitHubでソースを公開したりしている。
特に、さくらインターネット研究所の仕事は、アウトプットすることそのものがミッションとも言えるので、3月から始めたばかりの仕事だけど、早速ひとつアウトプットしてみた。
昨年の振り返りエントリで、「法人個人問わず事業全体の売上で言えば、2年目以降は割と安定している。今年も同じぐらいの売上になりそう」と書いていたが、実際その通りになった。今年は少し増えそう。具体的な金額については、個人法人含めて hXXsyotoku.pdfを公開する|mizzy|note という有料noteに書いた。法人の売上高はざっくりした金額しか書いてないけど。
7年かけて大学を卒業した。フリーランスになってからは、大学の授業をこなす時間を作りやすくなったような気がする(Serverspec本執筆時は除く)。
学位を授与された pic.twitter.com/xLrwjJHeQQ
— Gosuke Miyashita (mizzy) (@gosukenator) March 31, 2019
入学時と卒業時に書いたエントリはこちら。
フリーランスになった時に、10年ぐらいはこの働き方を続けたい、と思ったが、とりあえず目標の半分までは到達することができた。みなさんありがとうございます。
大学卒業が確定した pic.twitter.com/wEEXoUpCcY
— Gosuke Miyashita (mizzy) (@gosukenator) March 13, 2019以前 37歳で大学生になりました というエントリを書きましたが、7年かかってようやく卒業しました。在籍できる期間は最長8年間だけど、2年次から編入という形で入学したので、卒業できてもできなくても、今年度が最後でした。
仕事しながらの大学生活がどんな感じだったのか、振り返ってみたいと思います。
授業は以下の3つの形態になっています。
卒業には124単位必要で、自分は以前卒業した大学の32単位を持ち越すことができたので、実際には92単位を取得する必要がありました。
授業の具体的な内容は、以下のページから見ることができます。
最短で卒業することを想定した、年間辺りの単位取得数モデルケースは、1年次32単位、2年次32単位、3年次30単位、4年次30単位、となります。
また、授業開始は4月中旬ぐらいからで、Ⅳ期のレポート締切が1月初旬なので、授業をこなすのにあてられる期間は、1年間のうち実質的には9ヶ月ほどしかありません。
で、32単位取得しようとすると、16科目受ける必要があるので、大体1ヶ月に2科目こなす必要があります。テキスト授業やメディア授業は1科目が15章に分割されているので、1日に1章こなせば、最短で卒業できる計算になります。といっても、必ずしも毎日授業をこなせるわけではないですし、レポートを書くための時間も必要なので、1日1章だと時間が足りなくなります。
1年目は32単位取得できたのですが、なかなか大変でした。平日は朝会社についてから始業時間までの30分、昼休みの1時間、家に帰ってから1,2時間、といった感じで授業に時間を割いていました。土日も2,3時間は授業をこなすのに割り当ててました。また、出張先のホテルで授業をこなしたり、年末年始関係なくレポートを書いたりもしてました。
微分方程式でロケットの最大速度と到達高度を計算してる。(大学の応用数学課題レポートです。)
— Gosuke Miyashita (mizzy) (@gosukenator) December 30, 2012
ロケットの高度計算の積分やってたら年明けてた。おめでとうございます。
— Gosuke Miyashita (mizzy) (@gosukenator) December 31, 2012
本業があまり忙しくなく、残業がほとんどなければ、これぐらいのペースで授業をこなすことはできるのですが、本業が忙しくて残業が多くなったり、本業以外の仕事(自分の場合は雑誌や本の執筆)が重なったりすると、並行して授業もこなすのはかなり厳しいですね。
勤め先が提供しているサービスで大き目のインシデントが発生した時は、リカバリ作業のヘルプで徹夜対応して、そのまま試験会場に向かう、なんてこともありました。
そうだ、、mizzyさん朝まで対応してから試験受けに行かれてた… #ぶつかり稽古
— Shinya Tsunematsu (@tnmt) November 23, 2013
試験は無事合格しましたが、その後も事後処理などで忙しかったり、対応が終わって落ち着いたら一気に気が抜けたりで、この後はまったく授業が手につきませんでした。
また、Serverspec 本 の執筆中も、授業どころではありませんでした。
こんな感じで、7年かかってなんとか必要な単位数を取得できました。
以下が成績原簿です。「認定」と書かれてるのは、前の大学から持ち越して認定された単位です。
本業との兼ね合い以外だと、基本的には自学自習とあまり変わらないので、モチベーションの維持が一番大変でした。何度か途中で辞めようかな、と思ったこともありました。が、ここで辞めるとなんか負けた気がする、それは嫌だ、と思いながら何とか続けてこられました。
LMS(学習管理サイト)上に掲示板があり、そこで情報交換したり、実際に集まって勉強会をしたり、といったことも行われているようなので、モチベーション維持のためには、こういったものを活用すると良いかも知れません。
学ぶ内容は基礎的なことが多く、すぐ実践で役立つ、というものでもないので、これから仕事で役に立つかどうかはわかりません。
入学のモチベーションのひとつに、アメリカで仕事をしたい、そのためのビザ取得にはCS(Computer Science)の学位が必要だから、というのもあったのですが、今はアメリカに行く気はあまりないので、そのために学位を役立てる機会も今のところはなさそうです。
また、入学したときに書いたエントリに「情報工学や計算機科学なんかの学位を持ってない、といったことに、ほんの微か、あるかないかぐらいの、引け目なんだかコンプレックスだかなんだかわからないけど、そんなようなものをずっと持ち続けています。」とあります。これは今考えてみると、今後ずっとIT技術者として生きていくための、確としたバックグラウンドが欲しい、ということだったのだと思います。そういった意味では、この大学で学んだことや、最後までやりきって卒業できたことは、自分を支える確かなバックグラウンドの一部になったと思います。
なので、入学して良かったかどうかで言えば、まあ良かったんじゃないかと思います。
学士を取得した、となると、次は修士や博士、というのが自然な流れかな、でもまあすぐにではなく、ゆっくり考えよう、と思っていたら、ちょうどタイミング良く matsumotory さんからお声がけいただき、さくらインターネット研究所の客員研究員 になりました。ここから論文博士への道もあるかな、と考えています。
また、リモートでアメリカの大学院のCSの授業を取ってみた話 - k0kubun's blog を読んで、こんな風に大学院で更に専門的な内容を学ぶのも良さそう、などと思っています。
]]>分散型データセンターOSとリアクティブ性を持つコンテナ実行基盤技術のこれから - 人間とウェブの未来 を読んで、以下の様にツイートしたタイミングで、matsumotoryさん から「一緒にさくらの研究所で研究開発しませんか?」と誘われたのがきっかけです。
さくらインターネット超おもしろそう ー 分散型データセンターOSとリアクティブ性を持つコンテナ実行基盤技術のこれから - 人間とウェブの未来 https://t.co/j8OWjEEyvt
— Gosuke Miyashita (mizzy) (@gosukenator) December 26, 2018
ちょうど、今年度で 大学 を卒業予定で、次は修士や博士、というのも、選択肢になり得るかな、と考えていました。とは言え、すぐに具体的に動こう、と思っていたわけではなく、hyoshiok さんのように定年退職後に大学院に入る というのもありかな、ぐらいに、ぼんやりと検討していた程度。そんな感じで、研究者としてのキャリアについて漠然とながら考えていたところにタイミングよく声がかかったのと、それよりなにより、matsumotoryさんやさくらインターネット研究所の取り組みが、技術者としてとても面白そうなので、誘いを断る理由が一切ありませんでした。
先日、所長の鷲北さんが わしきたのこれまでの研究 開発と振り返り(2019年2月版) さくらインターネット研究所 定例 2019/2/20 というスライドを公開されていて、その中でさくらインターネット研究所の役割を、次のように述べておられます。
また、超個体型データセンターを目指す当研究所のビジョン – さくらインターネット研究所 という中・長期ビジョンも公開されています。
まだ自分の研究テーマは明確になっていませんし、研究者としてはひよこにすらなれていない卵の状態ですが、matsumotoryさんをはじめ研究所の諸先輩方から学びながら、研究所の役割を念頭に置き、研究所が掲げるビジョンの実現に向けて、自分が得意な技術領域で貢献できるよう、研究開発に取り組んでいきたいと思います。
]]>フリーランスとして食っていけなくなったのでアルバイト始めました pic.twitter.com/AG92ed5xsI
— Gosuke Miyashita (mizzy) (@gosukenator) March 23, 2018このツイートは、たまたまセブンイレブンの制服を着る機会があったので着てみたついでに撮影して冗談でツイートしただけ。ツイートした後に、あ、これエイプリルフールネタにとっておけば良かった、と思った。
昨年も一昨年と同様、リクルートテクノロジーズ ATL での仕事がメインで、それ以外には golang でミドルウェアを実装する仕事や技術顧問的な仕事が少し、という感じだった。
ATL の仕事としては、libspecinfra の開発をしていたけど、昨年いっぱいで契約が終了した。libspecinfra の開発は続けたいと思いつつも、仕事として時間が割けなくなったので、現在開発は停止状態。
ATL の仕事が昨年末で終了したことで、今年から仕事の仕方ががらっと変わった。昨年までは掛け持ちは多いときでも2社、大半の期間は掛け持ちせず1社だけ、という感じだったけど、現在は4社(リクルートマーケティングパートナーズ、タレンティオ、トレタ、アカツキ)を掛け持ちしている。また、ATL の仕事は現場から少し離れていたけど、今は割と現場に近い位置で仕事している。4社掛け持ち、コンテキストスイッチ大きそうだけど大丈夫かな、と思ったけど、ほとんどリモートでの仕事で、厳密に時間管理されているわけでもなく、曜日や時間が固定されているわけでもないので、自分の裁量で適当に時間配分しながら、今のところは無理なく回せている。
仕事内容的には、OSS(aktsk/nolmandy と aktsk/kalvados)の開発をしたり、OSやミドルウェアのアップグレードのお手伝いをしたり、監視周りの整備をしたり、ログ収集基盤の導入をお手伝いしたり、壁打ち役になったり、など様々。
ATL の仕事をしていた頃は、収入の9割を依存していたので、契約切れて次の仕事が見つからなかったら収入がなくなる、という不安があった。昨年9月にはこんなツイートしてる。
割と余裕どころか、来年から仕事なくなる可能性も出てきたので、仕事ください。 https://t.co/VjpP8FxL7a
— Gosuke Miyashita (mizzy) (@gosukenator) September 7, 2017
他にもこんな職探しツイートもしてた。
来年1月からの仕事が未定なので、これを実行する時が来たか https://t.co/Aj6EkIpJ8y
— Gosuke Miyashita (mizzy) (@gosukenator) November 13, 2017
ツイートしてたら仕事がもらえた。
ありがたいことに、色々お声がけいただいて、1月以降も妻と5人の子供を養っていけそうです。 https://t.co/20Ars6agrt
— Gosuke Miyashita (mizzy) (@gosukenator) November 30, 2017
昨年12月から今年1月にかけては、お声がけいただいた企業さんを訪問して話を聞いたり、仕事の詳細を詰めるための打合せをしたりで、外出することが多かった。2月以降はほとんど家で仕事していて、仕事で外出するのは月に2,3回程度になった。花粉症の季節にあまり外に出なくて良いのはありがたい。
4社掛け持ち、コンテキストスイッチの増大と、一社あたりにかける時間が減ることで、進捗が遅くなるというデメリットがあるけど、収入の依存先が分散されているという安心感もある。
@nagayama 氏につくってもらったカッコいい名刺届いた。オモテ面、ロゴと名前だけなのがインパクトあって良い。 pic.twitter.com/rw7a6GnQ6P
— Gosuke Miyashita (mizzy) (@gosukenator) February 27, 2018
仕事上、名刺がなくて困ることはほぼないので、つくらなくてもいいか、と思っていたけど、あると便利な時もあるので、法人化してから2年経ってようやくつくった。
フリーランスになってからの収入の構成要素、3年目に法人化したのもあって、以下のように変遷している。
個人事業収入は事業売上がすべて個人の収入、役員報酬は自分の会社の売上の一部が個人の収入になっている。なので、すべての事業売上が個人の収入となっている2年目が収入のピークで、3年目、4年目と収入は下がっている。
が、それはあくまでも個人としての収入の話で、法人個人問わず事業全体の売上で言えば、2年目以降は割と安定している。今年も同じぐらいの売上になりそう。
昨年末から今年の初めにかけて、コラムを3本寄稿して、インタビューを1本受けた。
コラムのうち2本は技術とはまったく関係ない、家のことについて書いた。
Twitter は優秀な職探しツール。