tech.guitarrapc.cóm

Technical updates

2018年を振り返って

2019年になって4日経過しました。

2017年の振り返りに続いて、2018年の振り返りをしてみます。

tech.guitarrapc.com

目次

総合

2018年の初めにこう書きました。

流れは年末から変わらず。C# / Swift / TypeScript / Serverless / Container がメインです。やること多いので、いっこずつ片付けます。 やりこんでできないより、やりきるは何より大事です。できるを最低条件に過程をよくするのは力量です。自分でハードルを挙げておいて、工夫してよじ登るのが続くのでしょう。 インフラ、サーバーサイド、クライアントサイドの視点からどうやるといいのかを考えられるようになったのが2017年の最大の獲得であり、今後試されます。

2018年はクライアントとサーバーサイドの両方をやっており、アーキテクチャから考えて実装までやることが多かったです。クライアントとしてはHoloLensアプリ開発に携わっており、2017年に得た蓄積を2018年発展させることになりました。サーバーサイド/インフラは、Python/C#/Docker/Serverlessが主になり、一方でSwift/TypeScript を触る機会がかなり減りました。クロスプラットフォームで動かすことが多いため、Golang を触る機会が明らかに増えたのも目立ちました。転職、起業が入って想定よりも少し色々やることになりました。

総じて、自分の経験を活かしつつ足りない部分を学びつつ適用していくことの連続でした。今までの延長のようで、実際はOS、クラウドともに環境を選ばなくなっており一部に安住も固定もできなくなったという意味で、自分の未熟さと向上が求められる一年でした。

退職と転職と起業

グラニ社は2018年退職しました。ちょうど5年いたことになります。入社当初から「3年経ったら辞める or @neuecc がいなくなる時は私もやめる」と伝えていたのですが、2年延長するぐらいには好きな会社でした。延長を振り返ってみます。

1回目の延長は3年経った一昨年で、「黒騎士と白の魔王」のリリースを見届けたいこと + ゼロからVR部門の立ち上げに誘われたことからあまり機会ないのと面白そうと思って伸ばしました。

2回目の延長は昨年で、部門立ち上げてアプリもいくつかリリースしたころで、「黒騎士と白の魔王」のリリース間近だった + クローズドβで問題が確認できないことから社内のモニタリング基盤を一新することになりリリースを成功させるために延長しました。

このモニタリングの変更によって開発から運用まで根底から取り組み変えることになったため、安定するまで見届けたいという思いがありました。このあたりはグラニの開発者ブログで書きました。

engineering.grani.jp

2018年は延長する理由がないので1月にいくつかお会社に訪問して、面白そうなプロジェクトに参画しようと考えていましたが身内の緊急事態があり断念することになりました。*1と思いきや3月に@neuecc が退任することになったので予定通り退職しました。グラニは、neuecc に誘われたから入りneueccがいるからいたという意味で、人に惹きつけられて働くという試みでしたが、想定以上に楽しく自分を鍛える場となりました、ひとえに多くの同僚と周りの人に支えられた結果だったので心から感謝しています。やりたいことと人と仕事が一致していたという意味でとても面白かったです。

3月いっぱいでグラニを退職することにしたものの、どこに行くか決めておらずいくつか会社を訪問し、4月に某社に転職し2週間で退職しています。人生で一番早かったのですが、入社までにかかわった方には申し訳ない限りです。入社や退職エントリーを書いていないことからも詳しい理由は書きませんが、あくまでも自分の想定との乖離が激しかったためであって、その会社やメンバーに起因するものではないです。詳しく聞きたい方はご飯に行きましょう。

で、5月に起業しました。2018年4月時点では後2年先になる想定だったのですが、2年で得るもの、やることを考えた末でした。*2多くの人に支えられてまずはスタートを切っています。知らないことばかりで頭が回らない、日々いっぱいいっぱい感がありますが、本当に周りの人に助けられています。とはいえ年末の2週間は、手痛いドジを2回踏み、日常生活すらも余裕を失い、体力も限界に近かったので2019年はこれぐらいは余裕でクリアできるはず。*3

さて、起業したものの2018年は一人会社なので個人事業主とあまり変わりません。*42018年は、知人の紹介や打診で複数のお会社でお手伝いをしています。

プログラミング

2018年は、前半と後半でやっていることが全く変わっています。 前半は、ASP.NET MVC から ASP.NET Core 2.0/Terraformがメイン、後半はお手伝い先に合わせていろいろでした。

最も使ったのは、C# ですが Golangを読む機会が大きく増えたように思います。

git コミットは、まぁこんなものでしょうか。PowerShell本のコミットが混じっていてちょっとノイズがはげしいです。

CSharp

お仕事としては、ASP.NET MVC の ASP.NET Core MVC 化が大きなトピックでしたがやり残しになったのが残念でした。 一方で、HoloLens + Unity でのお仕事があり、CI/CDの構築からサーバーサイド連携、MVP4U アーキテクチャなどチャレンジができたのは良かったです。

特にMVP4Uは、Zenject による DIをアーキテクチャのために使う失敗に対するカウンターになったのが大きく、DIに対する自分の中の一喜一憂が大きく浮き沈みしました。ASP.NET CoreのDIは、フレームワークが組み込んでしまっているので、どうこう考えるより先に使えばいいでもその場は構わないと思いますが、Unity のDIは自分で意図をもって用いることになり、ここで失敗をしたのは良かったです。現状Unity でDIは、テストかScriptableObjectの解決以外は使いたくないし避けていくと思います。

C# はUnityを除き .NET Core に集約されました。.NET Framework ありがとう、さようなら、でいいと思います。ぐっばい。とはいえ、macOS、Linux 使っていますが、.NET Coreなアプリを動かすことないんですよね、たいがいコンテナ上で動かしてサービス組むので、.NET Core というより、コンテナで動かせる *5という見方です。コンテナとして考えて、開発はC# でできるのはCI/CD、オーケストレーションの全方位でメリットなのでようやく追いついてきた感じがします。

面白かったのがUWPアプリを書いていたことです。HoloLens のごにょごにょで必要になり書いたのですが、昔からXAMLは苦手な部類にあってようやく書ききりました。書きやすいは書きやすいのですが、これを今後も続けるのはどうにもと感じるのでなんともです。UWPも制約の高さが結構あからさまに出てるのが微妙で悩ましいです。今後のUWP全然光が見えないのですが、本当にこれやるんですかね?

Serverless に関しては、Azure Functions v2.0 がGAしたことで、いくつか書き換えが入り ASP.NET Core っぽくなりました。暗黙的なお約束が増えたのがDIに似た気持ち悪さがあるのですが、フレームワークの成熟ってこういう感じかなぁとも感じるので、シカタナイ気もします。

1つ感じるのは、.NET Standard はかなりきつく、.NET Core 最高感です。特に .NET Core 2.2 から楽になった感じが大きいので、今後は .NET Core 2.2 /3.0 がスタンダードでいきたいところです。

相変わらずC# に感じるビルドが苦しいという状況は光明が見えないです。dotnet (msbuild) でのラップはいいのですが、制御しにくさがなかなか大きいです。

シングルバイナリくるくる詐欺が本当にくるっぽいので、期待しています。シングルバイナリ何がうれしいって、CI/CD/コンテナ でめちゃめちゃうれしいのです。

と書いていたところで、反応もらいました。

運用面はどうとでもなるんだけど、それはugly であることを受け入れた結果なので、ベストではないと考えています。シングルバイナリならコピーと参照がシンプルになるのは明らかです。 ファイルを指定するか、フォルダを指定するかの違いは思ったよりも大きくて、基本的に対象が単独ファイルであることは簡単です。とくにフォルダになった場合、子フォルダも考慮する必要が出てくることがほとんどなので、シングルバイナリの楽さに比べて格段にめんどくさいと常々感じます。シングルバイナリでないだけで、余計な手間とコストがかかっているので「2019年にもなってそんなこといい加減なんとかしたい」というのが気持ちの根底にあります。ただ、dll差し替えで済むケースなど部分的な入れ替えとか考えだすとアカンコレなのでバランスなのでしょう。

Python

お手伝いの流れで、メイン言語で読み書きをしていたという意味で触る機会が増えました。C#以外は全てVSCode なのですが、コードレンズで追っかけるのが楽なので始まりのエディタとしては良さがありました。もともと時々読み書きすることはあったのですが、VSCodeで案外楽になっていたのは良かったです。

某SDKを使っていたのですが、エラーから原因を追いかける時にスタックとレース通りではあるもののエラーメッセージから状況が読めず、周りからも同じ見解であるものの解消まで手間取ったというのがありました。デプロイしないと状況が発生しないこともあり、リモートデバッグどうすればいいんだ、となりながら苦しかったので対処知りたい。

pyenv 苦しいので、全面的にpipenv 使えばいいと思います。あとDockerではpyenv とかせず、おとなしくpython をいれましょう。その方がパスと依存性がきっちり制御できて時間短縮できます。pyenv やばい、pyenv 使いたくなくなった。

そういえば、Azure / AWS / GCP全て Python 3.x で問題なくなっているので、Python 2.x は使わなくなりました。

Golang

Windows/macOS/Linux 全ての環境を触ると出てくるのが、クロスプラットフォームで上手く使えるツールなのですが、Golang の独壇場でした。それもあり、OSSツールを使うことがほとんどなので、Golang を読む機会がかなり増えました。

一方で、余り書く機会を作れずにいたので、Golang書く機会を強制的に設けるようにしはじめました。どうしても必須なので、しばらく維持して書く機会を強制的に増やす方向にしています。

PowerShell

これまでと違ったこととして、2017年末に出版社様から打診をいただいたPowerShell本の執筆が決まり書き上げました。

tech.guitarrapc.com

反省も書いたので、次があれば生かすということで。

tech.guitarrapc.com

PowerShell 6.0 がリリースされ、6.1 がリリースされたことでPowerShellも .NET Core に踏み出しました。*6

PowerShell Coreについては本でも書きましたが、参考になるモジュールを用意していなかったので書いたのがUtf8BomHeader です。

tech.guitarrapc.com

私自身のPowerShell を仕事で用いる頻度は、Windows 100% なのですが、個人では60% Docker (Linux) / 40% Windows なのでまぁこんなものかもしれません。そもそもWindows以外の仕事でPowerShell を用いる理由がないのですが、Windows、特にAzureだと用いているのが楽なケースが散見されるのでまぁそんなものかと思います。

いろんなお会社でいろんなやり方を見ている限り、PowerShell Core はWindowsがない環境で標準的に使われるのはないと感じますがもう少し様子見で。Azure は PowerShell でしかできない操作があるの本当に良くないと思います。

ShellScript

PowerShell よりも圧倒的に書くことが多かったのは当然Dockerで使うからです。Terraform と組み合わせることが多く、このやり方はつらいことへの一直線なので悲しいものがあります。

ある意味では素直なので、このままちょくちょく書くことが多い状況は続くのでしょう。

インフラ

お手伝いで求められ、発揮しやすいのがインフラとアプリをつなぐ部分とサービス全体の安定化です。ということで、インフラ的な部分は2018年もやってます。

特に、Docker、 Terraform + Ansibleが多く、Kubernetes に少し踏み込んだ感じでした。

Terraform

一年通して、Terraform でした。

Azure/AWS/GCP どのプラットフォームも書いていましたが、どこも癖が違って微妙にやりにくいのが解消せず厳しい..... とりあえず、AzureRm Providerに関しては、10以上Issueあげたりしたので、2018年末はだいぶん楽になりました。2018年5月はどうしようかと思いましたが、なんとかなるぐらいにはなってよかった。

AWS がやはり一番書きやすいというかリソースがそろっている感じはあります。書きやすいというと嘘で、Regionが露骨に出てくるので、どうstateを分割するのかは悩ましいところがありますが、Organization含めて、アカウント分離はしやすく安定して模範的な環境だと思います。2018年は、年始と年末でだいぶんTerraform への取り組みや構成、CI、Atomic担保が構成、説明できるようになったので次に行きましょうという感じです。

GCP でも問題なく書くだけのリソースはあります。マルチクラウドがふつうなので、Terrafornを使うのは妥当な判断だと思いますが、もう少しいい手がないかは常に悩むものがあります。2019年はそこかしら。

なお、カクカク詐欺な記事を書いているのでちょっと待ってください。(いつリリースなの)

Ansible

Ansbile + Terraform + Packer はまぁ安定なのですが、あんまり好みではないのでいやですね。ここはもう少しなんとかならないかなぁ感とお付き合いします。

コンテナ

コンテナに関しては、普通に開発フローに組むのが楽で当然あってしかるべきな状況が一段と浸透しています。むしろコンテナを前提にしないとCI/CDの難易度が高いという方が適切かもしれません。

そういう意味では、.NET Core + k8s は良い流れで、来年はこれが普通かなぁと感じます。ローカル開発バックエンドならDocker-Compose でいいのですが。

AWS

2018年は、嫌い/苦手だったサービスに真正面から取り組んだのでちょっとは楽になりました。

Organizations をベースに、マルチアカウントも楽になっているので引き続き楽になっていくでしょうし期待です。

sts の改善や2018年re:Invent でAWSはいい感じにゆるさと硬さのバランスが取れてきたのはあって、とてもバランスが良くなったように感じます。

Azure

2018年最も触ったクラウドはAzureになりました。

Portal を除き、Terraformのみで扱える範囲に関してはずいぶんと楽になりました。一方でリソースの生成、削除の時間のかかりよう、Atomic性が壊れる当りの挙動が一年通して安定しないのでそんなものかなぁと割り切っています。Preview だから、というのが出てきて一向にGAにならなかったりするのは苦しいものがあります。

MSI が使いやすいので、MSIを標準的に使いたいところです。

初期はいいけどサービススケール時以降は使いたくはない感じがありどうしようか悩ましいです。

AWSやGCP含めて使ってて感じるのは自分のサービスの最大の顧客が自分なんだなという感じに対して、「Azure の最大の顧客ってもしかしてMicrosoft じゃないのでは?」という感じがあり、Azure の今後に注目しています。

GCP

会社のメインクラウドはGCPです。理由はいくつかありますが、手間とスケールと安定のバランスから行くとちょうどいいというのがあります。

AWSだと手間が大きい、Azureは安定とバランスが好みではない、ちょうど自分がほしいのに近いのが現在はGCPです。

ヘビーに使うので、しばらくは注力が続くでしょう。

コミュニティ

2018年は、try! Swift や CEDEC に初めて参加しました。両方とても刺激的で面白かったです。会社のふるまいが見えるので、結構おススメです。

Yamagoya Meetup 2019やGoogle INSIDE、Serverless Conf 2018 も参加しましたが、最高でした。また参加したいぐらいには。

Unity 完全に理解したシリーズにも出てましたが、どれも学びがありました。「完全に理解した」は語句としては意味と内容がずれてるのでもう少しいい表現ないのかしら。

コミュニティに人が多いと私はすぐに逃げてしまうので、コミュニティ後の食事とかで見かけたらレアです。必要がない限り、今後も逃げると思います。

2018年は、書いているセッションノートを即公開することを試みてみました。Kibela にセッションノートを書いているのですが、これをそのままはてなブログに張り付ける方式です。ここ数年文章構造を作りながら書くようにしているので余り困らない感じがあります。

記事

21本、すくないです。PowerShellが多いのはいいですが、あんまりよくないです。お手伝い先で週2-4本書いているのでそこで体力使っている感じがあります。2019年は、公開前提で書けるといいかもなので調整してみます。

ライフスタイル

睡眠時間が年間平均3時間10分だったので、もう少し寝るようにします。また、ランチを抜くとかなり快適に一日を過ごせるのが分かっており、朝夜ご飯を徹底するのがよさそうです。昼食べる場合は、炭水化物を抜けばよさそうです。

PCの利用状況、睡眠リズム、徒歩数を計測することで、ある程度自分の傾向と反省を週一で促せるのでキープするとよさそうと感じます。また、ストレッチをしていると体が楽なので、これも継続がよさそうです。

さて、自分の欠点である「個人に依存することはエンジンがかかるのが遅い」を解消するために以下の対策をうちました。

  • 消費時間を計測する
  • Youtube をウェブサイトブロッカー (Beta) でブロックする
  • 期限を設ける
  • 一人でもセルフレビューをいれる

エンジンがかかるのが遅いのは他のことに時間を費やすことから見えるはずなので、何にどれだけ時間をかけているかを計測することを始めました。 私は、Windows / macOS両方を使うので、Rescue Time を使って一日のざっくりとした時間消費を測っています。

www.rescuetime.com

私は普段 Chrome を使っているのですが、自宅の環境でウェブサイトブロッカー (Beta) を使うことで、Youtube を完全にブロックしました。iframeは見れるので、何かの記事のYoutube閲覧には困りません。

期限に関しては、Google Calendar でこまめにスケジュールに組むことを徹底することで、上手くいっています。

セルフレビューは、Geekbot を用いて自己報告をしています。感じるのは、「年配の経験つまれた方に一日1回レビュー受けるサービス」受けたいなぁと。*7

2019年は?

会社としては、2019年は作りたいサービスを形にして何本かリリースするため働き方をシフトします。*8 個人は、会社のサービスリリースと収益化です。注力する言語的にはC# / Golang 、ツールはTerraform + Kubernetes + GCP/AWS/Azure + Unityです。

2019年は2018年より、さらに(自他に)求められるレベルが高くなっており、天井知らずを感じつつ楽しみたいと思います。

あとは自分の習慣の改善なので、ガンバリマス。

*1:予定になく先方にも申し訳なかったです

*2:予定では7年前に起業だったので予定より遅れた

*3:あるいは働き方を変える

*4:事業計画通り

*5:Windows Containerではない

*6:リリースして初めて踏み出せる

*7:なんていうんでしたっけ、すごいいいなぁと思ったけど忘れました

*8:事業計画通り

PowerShell 本を出版するまでの反省

PowerShell本を書いたのですが、当然多くの反省があります。

tech.guitarrapc.com

どれも自分の苦手とすることへの直視を求められるのでメモしておきます。

プログラミング系の本を書くときの参考になれば幸いです。

目次

そもそもなぜ本を書いたの

本を書く動機はいろいろなケースがあると思います。

私の場合、本を書きたいというより「本を通してPowerShell に感じる悩ましいと思わせる部分への一定の解消を図りたい」という思いで書きました。 結果は読者のみぞ知るので分かりません。

もともと私が持っていたPowerShellの課題に「学習コストが高すぎる」というのがあります。ただコマンドを実行するだけならいいのですが、適当に書いたスクリプトがよくわからないけど動かない、意図した結果にならないというのは、今でもそこかしこで見ます、聞きます。「PowerShellは学の大変だから触るのすら忌避する」という声をよく耳にするたびに、ナルホドタシカニと感じてきました。

自身、今まであったPowerShellの本で自分の知りたいことが知れず、手さぐりで学んできた部分が大きいです。PowerShell InActionは良い本ですが、この本でPowerShellに感じる苦しみは解消されませんでした。配列やスコープは理解できず、モジュールも何それです。英語出版本も10冊近く持っていますが、どれもスコープは小さく、知っている前提、レール上で使う前提でした。そのため、自分がやりたいことをやるためにPowerShell Utils などの小ネタ置き場を作ったり、モジュールを公開し、シェル芸を書き、一つひとつ学んだことを記事にしたり、MSDNやDocs が更新されると読んで新しいことを学び、誤りに気付き、理解のすり合わせを行う繰り返しをしています。

この状況は、ブログを書いていても「調べることができる人」という条件がつくためリーチ層が限定されます。そこで、編集者さんからお話をいただいた時に、リーチできない層に対して、次のニーズを満たすものを伝えるものがないなら書こう、それを書けせてもらえるなら書くというのがこの本の根幹です。

  • 学ぶコストを減らすため一冊で全然書いたことがない人、書いたことあるけどただコピーしただけ、ちょっと書いてる、普段から書いてる、めっちゃ書いているをある程度網羅する *1
  • とりあえずこれ読めば罠とか理解して回避方法もわかる
  • どう書けばいいかのサンプルが分からない状況にサンプルを提供する
  • 後でわからない時にでも読みなおせる
  • 途中まで読んで、分かるようになったときに先も行ける、

執筆期間

本どれぐらいで書いたのか度々聞かれます。だいたい2カ月です。

内訳は、1-2月の深夜、3月半月 + 4月半月 + 5月半月。 3月以降は仕事がないので一日12-18時間ぐらい当ててたようです。*2

仕事をしながら書ける人、心底尊敬します。気持ちの切り替えがポイントなのですが、難しいと感じました。

反省点

いずれも自分への甘えと見込みの甘さが露呈することになります。

書き始めるまでの重さ

最も反省するべきは、エンジンがかかるまでが遅いという悪い癖が露骨に出て足を引っ張りました。

本は書きたい、締め切りもあり書かなきゃなのですが、どうしてもVS Codeを開くまでの気持ちを持っていくのがムズカシイ時期がありました。 仕事をしている時の深夜、締め切りを意識していない時、意識し始めた時それぞれでまんべんなくあるので、私の欠点です。

対策

  • 時間を消費していたことをしようとしたときに閉じる (主に読書とYoutube が大きかったように思います)
  • 音楽を決める

もともとYoutubeでバックグラウンドミュージックを書けて、プログラムや記事を書く習慣があります。が、この時期に動画の音楽を流すことをしてたせいで動画を見る、映像に注目する悪い癖がつきました。そのため、Youtubeで一日の時間が溶けることもあり、開くのをやめました。小説は気分転換がずるずると、パターンだったのでそもそも開かないことにしました。

音楽は意識を集中させるために使っているので、実はなくても書けるのが分かっています。事実、音楽が途中で切れてても一日中書いていることも多いです。しかし音楽を使って意識を書く方に集中させる、書くことの環境であると自己暗示書けることに使っているためある方がスムーズに書き出します。そこで、Playlistを決めて、エンドレスに流すことで、音楽と執筆を結びつけました。主に "Put Your Hearts Up"が多かったです。

一日の書ける量

色々な方が書かれていますが「ブログと全然違って全然書けない」です。「適当を書けない」という当然の事実がびっくりするぐらい書けなくしました。まさか一日10P程度も書けないことがあるとは思いませんでした。*3結果、締め切りを延長したにも関わらず直前まで修正していたので、本当に余裕ありませんでした。

文章構造も書きにくさの原因でした。私が読書をしていて一番嫌いなのが、事前に知らないことを先に出して後から説明されることです。*4知らない概念を先に出した場合、思考のジャンプが生じるためかなり嫌っています。今回、自分で書いていて発生したため、文章構造を5回書き換えています。始めに目次とプロットを書いていても発生したので、レビュー時に考えることにしてある程度割り切りました。*5

私は、RE:View を使っていたのですが、初めてのRE:Viewによる書きにくさは一週間程度ありました。その後もプレーンテキスト書くよりもRE:View書式当てることの手間はありますが書ける量はそこに起因していないように思います。

対策

  • プロットを細かく出す
  • 今日はここまでという目標スケジュールを紙に大きく書いて共有しました
  • 文章構造をブロックごと入れ替え、つなぎはレビューまで割り切る
  • 事実に基づいて淡々と書いてから肉付けをする

プロットと一日に書けるページ数(10P-50P)をある程度同期させることでスケジュール管理しました。同期が崩れると進捗が不明で完了が未定になるので、これはマストな約束事として自分の中で持てました。

目標の達成度を見える化することで、プレッシャーを外部から与えてもらいました。案の定レビュー時に入り乱れて機能しなくなったのですが、文章を書いている分には、自分のダメ具合が露呈するのでオススメです。

「文章構造を考えながら書く」のと「ブロックごとのテーマについて書く」では、難易度がけた違いです。ブロックごとのテーマに集中するのは非常に簡単で、ブログが書きやすい理由はこのテーマが決まっていることにあります。本を書くときに「全体の構成を考えながら書く」のは、章ごとに分離しても難易度が高いため辞めました。ブロックごとに書くようにしたことでかなり書きやすくなりました。

文章に肉付けされていると前後の文脈が作られてしまい、ブロックごとの移動をする修正が困難です。淡々とした文章で書いておいて、文脈を整えるようにすると移動が楽になりました。文章を書く基本なのでしょうが、なかなか気づけず無駄に時間を使いました。

表現の難しさ

網羅するというのが本当に厳しく、文言の表現でも悩みがずっと解消できなかった部分です。そのため、文章に日本人じゃないんじゃないか、というレビューはそうですねと感じます。誤字脱字の多さもレビュー時点から指摘を受けています。編集者さんの修正が結構入っているのですが、それでも誤字脱字あるので元がまずいのは明らかです。

対策

  • もっとすっきりした文体にする

最終版でも、文体がくどいためすっきりしていいと感じます。

ページの超過

当初、編集者さんと合意した目標ページは400Pです。蓋を開けると624Pでした。まさかの224P超過、いいわけもありません。Goを出してくださった編集者さんにはお礼しかありません。

対策

  • プロットをきっちりねる

中盤にプロットを練りなおした時に誤差が小さくなったことからも、当初の見込みの甘さは明らかです。 この影響は多きく、最も面白いであろう5章がページ相対量が少なくなっているのは完全な失敗でした。

サンプルコードの担保

自分が読んでてほしいので、サンプルコードをふんだんに入れましたが、その動作確認をWindows PowerShell / PowerShell Core (Windows / macOS / Linux) の書く環境で行うことが思った以上にコストになりました。

対策は次の通りです。

  • サンプルコードに依存する文章だけコードの変更がないように気を配り、他はコード修正を前提にする

本質的には、マトリックスでクロスプラットフォームテストをかけるのがいいのですが、執筆中にテストを用意するのが過負担でした。誰かにお願いすればよかったです。

兼業はできない

1-3月を通して日中仕事している時に夜書くのは私にはムリでした。1章は深夜1カ月 + 3月の数日を当ててようやく書きましたが、非常に苦しかったことを覚えています。

また、退職と無職期間がまるまる執筆で費やされたのでのびのびできなかったのが悔やまれます。2018年の最優先課題だったのでシカタナイのですが、無駄に溶かした時間を考えると反省しかないです。

編集者との文章共有

GitHub + RE:View で書いていたのですが、編集者さんの印刷用割り付けとGitHub が連動できなかったことが悔やまれます。 編集者さん側の文章をGitHubにわざわざ反映してもらう必要があり、2度手間どころではありませんでした。 RE:View を用いたにも関わらず、RE:View で書籍製本もできなかったので、いろんな意味で悔いが残ります。

対策

  • 編集者さんに合わせる重要性を理解してもらう
  • 編集者さん側の文書フォーマットに合わせるなり、完全に同一フォーマットを用いる
  • Diff を活用する

なに使っていますか? これでいいですか? というすり合わせをはじめにやっていますが、こちらの自由でいいといわれた時に、この問題を予見できなかったのは自分の未熟を感じます。

手間をなくすためには、同一フォーマットを使うのが最善です。これはWeb寄稿ではなかった課題で、結構難しいと感じました。GitHub + RE:View or Markdown が標準になると、私は嬉しいですがどうなんでしょうか。

Diff を活用は実はしていたのですが、フォーマットが同じでないので漏れをお互いにシステム的になくすことができなかったのはムリゲー感じます。

重版予定は?

今はありません。本が分厚く余り出ない一方で、電子書籍が良く売れているということで鈍器なんでしょう。

もし重版が出るなら誤字脱字や表現上の修正、PowerShell Core 6.1/6.2の対応をしたいのですが、予定は未定です。

*1:この時点で欲張り

*2:ぜんぜん遊べておらず仕事よりハードでした。

*3:ブログの文章換算で甘く見てました

*4:言葉を置き換えて先に出すのはいい

*5:案の定レビューで指摘を受け、粛々と直しました

PowerShellでマルチプラットフォームに動くモジュールの作成と継続的なテスト

この記事は、PowerShell Advent Calendar 2018 の 22日目です。

qiita.com

今年は、PowerShell Coreについて本を書いたのですが、その中で書ききれなかった.NET Core と .NET Framework の両方で動くPowerShellモジュールの実用的なサンプルです。

目次

目的

このサンプルを作った目的は、単純に自分が書いていて自分のために用意した環境が汎用的に使えるものだったのでオープンにしただけです。(正直)

ただ、その背景にはいくつか動機があります。

  • 最近.NET は .NET Coreでしか作らないこと
  • PowerShell モジュールを作ろうという機会があった
  • CIで継続的に実行可否をテストしたい
  • ビルド環境につかれたのでDockerでビルドしたい

これらの例は本で提供するには紙面の見せ方も難しく、あの本でやるにはスコープを外していました。 今回の記事はそういう意味では本の補足記事になります。

Utf8BomHeader

非常にこじんまりとしたモジュールを作りました。実装は Utf8BomHeader.psm1 ファイル1つ、PowerShell Gallery で公開するためにUtf8BomHeader.psd1 を一つ追加しただけです。

github.com

このモジュールはファイルのUtf8Bomを扱うだけのもので、Windows 10、MacOS (mojave), ubuntu上で動作を確認しています。PowerShell 5.1以上、PowerShell Core 6.0 以上で動作します。

動機

Windows と Linux の相互対応、あるいはWindowsでクロスプラットフォームで動くものを動かす時、そのどちらでも課題になるのがファイルのエンコーディングです。 特に、Utf8 の BOMはWindowsでBOMが意図せずつくことがあったりして厄介度が上がっているように思います。

皆さんも Docker for Windows でDockerにファイルをmountで渡したときにファイルエンコーディングで怒られた経験をお持ちなのではないでしょうか? あるいは、GoやPythonでクロスプラットフォームに動く前提で作られたものが求めるファイルエンコーディングも通常は Utf8noBomです。

モジュールができること

このモジュールが提供するのは4機能だけです。

  • Test : utf8bom の有無をテストします。BOMがあれば trueです
  • Get : ファイルを先頭から読んでバイナリを表示します。デフォルトは3バイトです(BOM分)
  • Remove : ファイルのBOMを削除します
  • Add : ファイルにBOMを追加します
  • Coimpare : 2ファイル間でそれぞれのBOM結果を出します

実装について

少し実装について触れましょう。 当初PowerShell のみで書いていたのですが、ファイルをストリームで読むためのDisposeのために関数用意するのも冗長になるのも嫌です。 サンプルとして、Test-Utf8BomHeade のPowerShell 版は次のようにFileStream を開いてヘッダを読むことになります。

gist.github.com

本でも書きましたが、リソースの自動破棄は簡単な Using-Dispose 当りの糖衣関数を書いてもいいのですが、あまりスクリプトブロック内部で例外を起こしたくもありません。

そのため、今回のモジュールはインラインで定義した C# で実装を書いて、PowerShell はAdd-Typeでオンザフライにコンパイルしています。

https://github.com/guitarrapc/Utf8BomHeader/blob/94af0c001495a9a49a6bce53f207f5df09cf54a5/src/Utf8BomHeader.psm1#L1-L104

C# はNET Coreで動作することだけ気を付ければたいがい問題ありません。読み込んだC# クラスをPowreShell から呼び出すようにすると先ほどの実装が次のようになります。

gist.github.com

やりたいことだけ、という感じでシンプルになります。 さて、インラインでC#コードを文字列で書くのはよみにくいですね? 私も同意です、PowerShell の外に C# コードを定義したファイルはGitHub上でコードハイライトが利いたり、VS Codeで単品で動かせるメリットがあります。しかしビルド、展開、利用を考えるとファイルは少ない方が取り扱いが圧倒的に楽なため、インラインに定義できるならそうするのをオススメします。

今回はC# で実装を書きましたが、もちろんPowerShell で書くのほうが楽なことも多いです。気を付けるといいのはPowerShell Core と Windows PowerShellで両方動くようにするための抽象化は余り頑張らないようにした方が「書くのが苦しくない」ということです。いちいち互換性を気を付けることも、互換性の抽象化レイヤーを書くのもどちらもやりたいことではありません。私は苦しいのが嫌なので楽をするためにもC# で書きました。C# なら言語レベルで .NET Framework / .NET Core で気を付けることはかなり少ないので選択したということです。

CI

今回はCIとして Appveyor を用いました。 2つのパターンでビルドを用意しました。

  • appveyor 提供の ubuntu18.04 での .NET Coreを使ったビルド
  • Microsoft/PowerShell 提供のDockerを使ったビルド

自前のDockerイメージを使うとどこのCIという縛りはありません。

PowrShell でコンテナを使ったビルド? 大げさでしょうか?ビルド、テストにコンテナを使うことで、普通のプログラミング言語のビルドと同様にビルド環境を選ばなくなります。自分のコードの実行を各種環境で検証することも容易になり、ビルドしたらもうその環境はクリーンなDisposableが担保されます。いろんな環境への可搬性を考慮するとコンテナを用いないという選択はないでしょう。

Appveyor 提供のビルドイメージを使ったビルド

さて、AppVeyor はビルド環境イメージが定義されています。

www.appveyor.com

このイメージにはあらかじめ開発ツールがインストールされていおり、PowerShell Core も ubuntuイメージに含まれています。

www.appveyor.com

仮にappveyor提供のubuntuイメージでやる場合、これぐらいのカジュアルな内容でいけます。 今回は、cd を使っているあたりなんというかそういう感じって感じです。

gist.github.com

では独自のdockerイメージではどうなるでしょうか?

独自Dockerイメージを用いた場合のビルド

Dockerイメージは、Microsoft/PowerShell 提供のmcr.microsoft.com/powershell:6.1.0-ubuntu-18.04を使います。Pesterだけ入れて、プロジェクトを突っ込みましょう。

gist.github.com

appveyor.yml は次のようになります。

gist.github.com

先ほどのAppveyor提供のubuntuイメージくらべると、各種コマンド部分がそのままDockerコンテナでの実行に代わっただけです。こういった簡便な違いで済む割に、コンテナ内部の依存性はDockerfileで統一されるので敷居は低いでしょう。

ただし、mcr.microsoft.com/powershell:6.1.0-ubuntu-18.04 で1つ気になるのが、dotnet が叩けず、Publish-Moduleが実行できないことです。 Artifactなので外に出せばいいので別にいいというわけにもいかない場合があるのでちょっとどうしようかという感じです。

Appveyor のdockerを用いる場合の注意

AppveyorでDocker Imageをビルドする時は、services定義とbefore_build を使うのがプラクティスになっています。dockerは、linux image でdockerサービスの起動をかけることで利用できるので、servicesセクションを appveyor.yml 冒頭に定義しておきます。

services:
- docker

install: よりも後でしかservice startさればいため、docker buildbeffore_build:あたりでします。この実行タイミングはドキュメントになくてここで説明されています。

Build failed: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running? / Problems / Discussion Area - AppVeyor Support

テスト

テストは、PowerShell の標準的なテストツールである Pester を用いたユニットテストとしました。 ここまで小さい機能だと、ユニットテストが使うシーンそのままなのでシナリオテストにもなります。

Utf8BomHeader/Utf8BomHeader.Tests.ps1 at master · guitarrapc/Utf8BomHeader · GitHub

重要なのはテストを書くことではなく、継続的にテストが回ることです。 テストはCIと一緒にやることで初めてスタート地点に立つのはPowerShell モジュールでも変わりません。

なお、テストカバレッジは Peseterで出せるので、適当にこんなコードでREADME.md を書き換えたりもできます。

gist.github.com

あとは適当に remote push しましょう。

environment:
  access_token:
    secure: zYCOwcOlgTzvbD0CjJRDNQ==

on_success:
  - git config --global credential.helper store
  - ps: Add-Content "$HOME\.git-credentials" "https://$($env:access_token):x-oauth-basic@github.com`n"
  - git config --global user.email "Your email"
  - git config --global user.name "Your Name"
  - git commit ...
  - git push ...

成果物の取得

ビルドして生成された成果物は Artifacts でアップロードしてあげればいいでしょう。

https://ci.appveyor.com/project/guitarrapc/utf8bomheader/branch/master/artifacts

ビルド結果

ログがすぐに吹き飛ぶのでキャプチャで。

Build started
git clone -q --branch=master https://github.com/guitarrapc/Utf8BomHeader.git /home/appveyor/projects/utf8bomheader
git checkout -qf ecf403c5fa0975688503c2c74a15a4837ed62e93
Running "install" scripts
pwsh --version
PowerShell 6.1.1
Starting 'services'
Starting Docker
Running "before_build" scripts
docker build -t utf8bomheader_build:latest .
Sending build context to Docker daemon  175.6kB
Step 1/5 : FROM mcr.microsoft.com/powershell:6.1.0-ubuntu-18.04
6.1.0-ubuntu-18.04: Pulling from powershell
124c757242f8: Pulling fs layer 
Status: Downloaded newer image for mcr.microsoft.com/powershell:6.1.0-ubuntu-18.04
 ---> bcea40fb0698
Step 2/5 : WORKDIR /app
 ---> Running in e03532abc50f
Removing intermediate container e03532abc50f
 ---> 40e5cd66d690
Step 3/5 : COPY . .
 ---> a391219f8b2e
Step 4/5 : RUN pwsh -c Install-Module Pester -Scope CurrentUser -Force
 ---> Running in 20dab6bbeaf2
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 Installing package 'Pester'                                                        Downloaded 0.00 MB out of 0.69 MB.                                              [                                                                    ]                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      Removing intermediate container 20dab6bbeaf2
 ---> 8bee724ae30b
Step 5/5 : ENTRYPOINT [ "pwsh", "-c" ]
 ---> Running in a365d19ff2e5
Removing intermediate container a365d19ff2e5
 ---> 138aa32dca7b
Successfully built 138aa32dca7b
Successfully tagged utf8bomheader_build:latest
docker image ls
REPOSITORY                     TAG                  IMAGE ID            CREATED                  SIZE
utf8bomheader_build            latest               138aa32dca7b        Less than a second ago   369MB
mcr.microsoft.com/powershell   6.1.0-ubuntu-18.04   bcea40fb0698        2 months ago             367MB
Running "build_script" scripts
docker run --rm -v "${APPVEYOR_BUILD_FOLDER}/publish:/app/publish" utf8bomheader_build:latest "./build_psd1.ps1 -Version ${APPVEYOR_BUILD_VERSION}"
    Directory: /app/publish
Mode                LastWriteTime         Length Name
----                -------------         ------ ----
d-----         12/22/18   7:16 PM                Utf8BomHeader
7z a "${APPVEYOR_BUILD_FOLDER}/publish/Utf8BomHeader_${APPVEYOR_BUILD_VERSION}.zip" "${APPVEYOR_BUILD_FOLDER}/publish/Utf8BomHeader/"
7-Zip [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21
p7zip Version 16.02 (locale=C.UTF-8,Utf16=on,HugeFiles=on,64 bits,2 CPUs Intel(R) Xeon(R) CPU @ 2.30GHz (306F0),ASM,AES-NI)
Scanning the drive:
  0M Scan  /home/appveyor/projects/utf8bomheader/publish/                                                         1 folder, 4 files, 17125 bytes (17 KiB)
Creating archive: /home/appveyor/projects/utf8bomheader/publish/Utf8BomHeader_1.0.69.zip
Items to compress: 5
  0%    
Files read from disk: 4
Archive size: 5053 bytes (5 KiB)
Everything is Ok
Running "test_script" scripts
docker run --rm utf8bomheader_build:latest "Invoke-Pester -CodeCoverage src/Utf8BomHeader.psm1"
Executing all tests in '.'
Executing script /app/tests/Utf8BomHeader.Tests.ps1
  Describing Utf8BomHeader
    [+] Test should be pass for bom 1.2s
    [+] Test should be fail for bomless 75ms
    [+] Add should append BOM 45ms
    [+] Add should not operate when BOM already exists 44ms
    [+] Add -Force should append BOM even already exists 26ms
    [+] Remove should not contains BOM 33ms
    [+] Remove should not operate when BOM not exists 20ms
    [+] Remove -Force should remove BOM even already not exists 38ms
    [+] Compare should return == when both contains BOM 25ms
    [+] Compare should return <= when reference not contains BOM 28ms
    [+] Compare should return => when difference not contains BOM 16ms
    [+] Compare should return <> when reference & difference not contains BOM 17ms
Tests completed in 1.58s
Tests Passed: 12, Failed: 0, Skipped: 0, Pending: 0, Inconclusive: 0 
Code coverage report:
Covered 44.62% of 65 analyzed Commands in 1 File.
Missed commands:
File               Function             Line Command
----               --------             ---- -------
Utf8BomHeader.psm1 Add-Utf8BomHeader     130 if (!$Force) {...
Utf8BomHeader.psm1 Add-Utf8BomHeader     131 $header = [FileHeader]::Read($F...
Utf8BomHeader.psm1 Add-Utf8BomHeader     132 if ($header -eq $bomHex) {...
Utf8BomHeader.psm1 Add-Utf8BomHeader     133 Write-Verbose "Bom already exis...
Utf8BomHeader.psm1 Add-Utf8BomHeader     137 Write-Verbose "-Force paramter ...
Utf8BomHeader.psm1 Add-Utf8BomHeader     139 [FileHeader]::Write($File, $Out...
Utf8BomHeader.psm1 Remove-Utf8BomHeader  175 if (!$Force) {...
Utf8BomHeader.psm1 Remove-Utf8BomHeader  176 $header = [FileHeader]::Read($F...
Utf8BomHeader.psm1 Remove-Utf8BomHeader  177 if ($header -ne $bomHex) {...
Utf8BomHeader.psm1 Remove-Utf8BomHeader  178 Write-Verbose "Bom already miss...
Utf8BomHeader.psm1 Remove-Utf8BomHeader  182 Write-Verbose "-Force paramter ...
Utf8BomHeader.psm1 Remove-Utf8BomHeader  184 [FileHeader]::Remove($File, $Ou...
Utf8BomHeader.psm1 Get-Utf8BomHeader     218 $header = [FileHeader]::Read($F...
Utf8BomHeader.psm1 Get-Utf8BomHeader     219 Write-Output $header
Utf8BomHeader.psm1 Test-Utf8BomHeader    258 $header = [FileHeader]::Read($F...
Utf8BomHeader.psm1 Test-Utf8BomHeader    259 Write-Output ($header -eq $bomHex)
Utf8BomHeader.psm1 Test-Utf8BomHeader    259 $header -eq $bomHex
Utf8BomHeader.psm1 Test-Utf8BomHeaderPS  281 if ($PSBoundParameters.Contains...
Utf8BomHeader.psm1 Test-Utf8BomHeaderPS  282 [System.IO.FileStream]$stream
Utf8BomHeader.psm1 Test-Utf8BomHeaderPS  284 $stream = $File.OpenRead()
Utf8BomHeader.psm1 Test-Utf8BomHeaderPS  285 $header = (1..3 | ForEach-Objec...
Utf8BomHeader.psm1 Test-Utf8BomHeaderPS  285 1..3
Utf8BomHeader.psm1 Test-Utf8BomHeaderPS  285 ForEach-Object {$stream.ReadByt...
Utf8BomHeader.psm1 Test-Utf8BomHeaderPS  285 $stream.ReadByte().ToString("X2")
Utf8BomHeader.psm1 Test-Utf8BomHeaderPS  286 Write-Output ($header -eq $bomHex)
Utf8BomHeader.psm1 Test-Utf8BomHeaderPS  286 $header -eq $bomHex
Utf8BomHeader.psm1 Test-Utf8BomHeaderPS  289 $stream.Dispose()
Utf8BomHeader.psm1 Test-Utf8BomHeaderPS  293 [System.IO.FileStream]$stream
Utf8BomHeader.psm1 Test-Utf8BomHeaderPS  295 $stream = [System.IO.FileStream...
Utf8BomHeader.psm1 Test-Utf8BomHeaderPS  296 $header = (1..3 | ForEach-Objec...
Utf8BomHeader.psm1 Test-Utf8BomHeaderPS  296 1..3
Utf8BomHeader.psm1 Test-Utf8BomHeaderPS  296 ForEach-Object {$stream.ReadByt...
Utf8BomHeader.psm1 Test-Utf8BomHeaderPS  296 $stream.ReadByte().ToString("X2")
Utf8BomHeader.psm1 Test-Utf8BomHeaderPS  297 Write-Output ($header -eq $bomHex)
Utf8BomHeader.psm1 Test-Utf8BomHeaderPS  297 $header -eq $bomHex
Utf8BomHeader.psm1 Test-Utf8BomHeaderPS  300 $stream.Dispose()
Collecting artifacts...
Found artifact 'publish/Utf8BomHeader_1.0.69.zip' matching 'publish/Utf8BomHeader_1.0.69.zip' path
Uploading artifacts...
[1/1] publish/Utf8BomHeader_1.0.69.zip (5053 bytes)...100%
Running "deploy_script" scripts
pwsh -file ./deploy_pagallery.ps1 -NuGetApiKey ${PS_GELLERY_RELEASE_API} -BuildBranch master -ModuleName Utf8BomHeader
"Appveyor" deployment has been skipped as "APPVEYOR_REPO_TAG_NAME" environment variable is blank
Build completed

まとめ

PowerShell Core 使っていくといいです。本にも書きましたが、PowerShell Coreは十分実用に到達して、すでにWindows PowerShell が及ばないレベルまでまともに動けるようになっています。

特に私の場合は、クロスプラットフォームで動作することを仕事でも私生活でも扱っているので、Windows PowerShell はたまに触るたびに本当につらいです。モジュールを作った動機もBOMごるぁ、だったのです。特にWindows で、PowerShell で書いていた、書きたい時にマルチプラットフォーム向けのファイルを吐き出したい時は抜群に使いやすいでしょう。

そして、CIは回しましょう。 PowerShell にはビルドがないのでCIはいらない? そんなことを言うのは3年前まではスルーでしたが、今は最低限でも担保したいテストを書いて、CIで継続的に回す方が自分にとって楽になることが多くなっています。

今後PowerShell のネタが PowerShell Core が大半を占めるようになることを祈ります。(個人の勝手なお願い

PS. 本当はAWS Lambda Runtime で PowerShell 動かして見せる。というのを書くかと思ったのですが、「毎年アドベントカレンダーを書いた後にもっとアドベントカレンダーは軽いネタをやるものだ。」と言われたので、今年はそのことを思い出して軽くしました。

オフトピック : もしも.NET Core + PowerShell Core を独自イメージにいれるなら

もし自分でインストールする場合に備えて、.NET Core / PowerShell Core のインストールステップも公開しておきます。.NET Core がubuntu で公開されているやり方にひと手間必要だったのでどぞ。

gist.github.com

.NET Core のMicrosoft Docページにもありますが、libicu60が必要なのですが .NET Coreのインストールページの説明にはなくてほげ、って感じです。apt-get install libicu60 でも入らないですし罠感はあります。

Serverless Conf Tokyo 2018 に来ている記事7 : Serverworks Session #ServerlessConf #serverlesstokyo

毎年参加しているServerless Conf Tokyoです。3回目になります。 集中力の限界なので、ここで終わりです。(途中で力尽きた

http://tokyo.serverlessconf.io/tokyo.serverlessconf.io

他のセッション

tech.guitarrapc.com

tech.guitarrapc.com

tech.guitarrapc.com

tech.guitarrapc.com

tech.guitarrapc.com

tech.guitarrapc.com

引用は私のコメントです。

目次

Title

Serverless Architecting and NoSQL Data Modeling for Successfully Microservices

Speaker

Masashi Terui

@marcy_terui

Slide

前提

AWS です。

Serverless で Microservice アプローチで問題なりやすいのは?

Function の粒度、切り方 サービスとしてのトレース

これらがいわゆるMicroservice と同様に懸念としてデてくる。

FaaS と DB

FaaS とRDBの相性は悪いのか

コネクションが都度破棄されるのでプーリングどうする? セキュリティ どうする? (VPCつなげないと認証強度あれ.....) VPCに入れるとENI作成のオーバーヘッド..... スケーリングが、厳しい.... まず垂直から検討になる。

FaaS とNoSQL の相性はいいのか

コネクションモデル がステートレス + HTPS IAM だでセキュリティ担保だよね。 スケーリングです。

で、どうしていく

という話ができないと、使い分けなんですよ、ではだめぽ。

目的のために最適化は違うことを踏まえる

やりかたはいろいろ

  • モノリシックに1つで処理
  • バックエンドAPIに分割
  • Microservice に分割して、データドリブンにつなげる

ここで話題とするのは、FaaS ごとにMicro Service にしてイベントドリブンにつなげましょう。

すべてのサービスはEventとActionの組み合わせ

Event をどのように処理すべきか。

原則として、Serverless のスケールアウトメリットを活かすなら非同期ベースに考える

  • 同期
    • API Gateway
  • 非同期
    • 直列
      • Kinesis Streams
    • 並列
      • SNS
      • SQS
      • StepFunctions

不安なのは、エラーハンドリングとなる。

  • 大事なのは、リトライできる仕組みにする。(リトラできないエラーは、1つのイベントとして通知させる)
  • モニタリング、トレーシングで必要な情報を集める

リトライアビリティはクラウドの基本だけど、冪等性、あるいは入力に対して常に同じ結果となるようにするのが重要。

どのように管理スべきか

  • Cloud Formation がいいと考えている
    • SAM / Serfverless Framework で管理すると楽

なぜかというと、Service の管理ができるから。

  • Event Srouce -> Action (Lambda) で紐付けられる
  • 宣言的
  • ImportValue /Ref

この意味で、CloudFormation はよくできている(書きにくいけど

ポイント

Event Source と Action 単位でStack を分けるのがいい。 EventSource を接続点として依存関係を集約できる。 非同期な関係性を重視することで依存関係の向きが揃う(循環依存がなくなりよい)

なぜここでClean Architecture をもってきたのか..... 文脈ちがうでしょ

Integration Test

SAM で、ステージ名をパラメータ化して、ステージごとのEventSour¥ce入れ替え。Mockを使ってDBを偽装。 入力をMock化するのでテストしやすい。 時間はかかるので基本CI化

Jenkisn や CircleCI のIDで一意なIDを取得、設定することで追跡も可能ですよ、と。

アプリケーション設計時のこつ

アプリケーション + DynamoDB 設計時のコツ

  • アプリケーションとデータモデルは同時に設計する
  • 書き込みと読み込みで都合いいデータを扱う
    • アイテムにまとめることで整合しを守る
    • 呼び込みは結果整合を受け入れて効率のよいジョインを

アプリケーション +RDS 設計時のコツ

Kibesis を噛ませてコネク暑中をおさえるのがいい。

Lambda に困っているるわけではない。

しっておくこと

  • 各データストアの特性
  • データ整合性を守る仕組み
    • ACID
  • データアクセス
    • B+ Tree Index

[ここで限界を迎えたのでおわり]

Serverless Conf Tokyo 2018 に来ている記事6 : Epsagon Session #ServerlessConf #serverlesstokyo

毎年参加しているServerless Conf Tokyoです。3回目になります。

http://tokyo.serverlessconf.io/tokyo.serverlessconf.io

他のセッション

tech.guitarrapc.com

tech.guitarrapc.com

tech.guitarrapc.com

tech.guitarrapc.com

tech.guitarrapc.com

引用は私のコメントです。

目次

Title

What We Should All Worry About When Monitoring Serverless Applications

Speaker

Nitzan Shapira @nitzanshapira

Slide

[]

Complexity and Monitoring

Serverless は複雑.... Resource は管理したい、Application はどんどん複雑になっていく..... 管理不可能になる前に関しを...。

Function は大事 (貴重)

  • Out of Memory
  • Cold start
  • Timeout

でもみたいのは、Service ですよー。

System > Function

これは重要で、System は、Functions + APIs + Transactions なので、Function の集合がサービスではない。 Function だけでは不十分、かつ、非同期イベントの関しまでトラブルシュートと修正には必要になる。

Distributed Tracing

Micro Service は、ロジックが個別に構成されている。 ロジックは関連を知らないので、同様にどのように接続されているのかを把握する必要がある。

Jaeger で可視化できるが、必要なのはどうやってそのデータを得るのか。

Manual Traces/Instrurentaion

このあたりをつかってやったり...。

  • OpenTracing
  • OpenCensus

やらないといけないことは多い。

  • Before and after call

Serverelss apps are very distributed

Complex Systems have thousands of functions What about the developer velopcity?

Exisiing Solutions?

  • AWS Cloud WatchLogs : ログは見れるけどそこまで
  • AWS X-Rays : Distributed ではあるけど、Lambda まで、AWS Service のプロファイリングに過ぎない
    • いわゆる Distributed Tracing ではない
    • 非同期イベントもおえない

縦串に処理を負えない、中途半端なTracing、APMになっている。起因がなにかを判別するのが難しいのがとてもじゃないけど、コレでは足りない。

Quick Look が重要

Serverless でスピードアップするので、Developer体験もスピードアップが必要。 そのため、Quick Loock として、トランザクション全体のリソース間の処理時間がぱっと見えるなどのレベルで簡単さが重要になる。

では、マニュアルでCloudWatch Logs を Lamnda で5分毎にスキャンしてRDSへ?

* CloudWatch がHighly Throttleに
* Request が時間かかるように
* 5K 同時Lambda for 5min はむりぽよ。

当然コストもべらぼうに高くなる。

まったくで、この常時起動 + Fanout手法でのServerless は地獄一直線なぁ

Obervability

ということで、X-Ray もだめ、マニュアルも厳しいので Epasgon ですよ。

https://epsagon.com/

Dynamic Service Map ビジネスフローを乗っけている。

Transaction の流れ、があるのはかなりいいのでは。 グラフDB使わないと関連クムのだるそうだな

ログインはこっちから

https://dashboard.epsagon.com/login

まとめ

トランザクションの流れは注目したいと思いつつ、どうやるかアイディアがわかなかったのでいい感じに思う。けど、正直StackDriverでID関連で組めないかなぁっていうのもあり.... 処理ごとにってなると手間だけど地道にいくしかないかなぁ