全員リモートの環境で「むきなおり」のワークを実施したので書き残す

昨今の情勢でうちの会社の開発部門は3月からほぼ全員がずっとフルリモートで働いている
そんな中だけど、1Qが終わったのでキリも良いからと普段の振り返りではなく「あるべき姿との差分を取るという目的で」むきなおりという手法でチームを振り返ってみた

この手のチーム活動系のワークをフルリモートでファシリテーションしたのは計画などの定常MTG以外では初めてだったのでどう実施したかやら感想やらを書いてみようと思う

むきなおりとは?

自分たちがあるべき姿というのを改めて確認し、今あるべき姿に進んでいけてるか?という観点で振り返るという手法
あるべき姿と現状をチームメンバーで出し合って、差分を取り、差分を埋めるためにどうすればいいか?を計画するのがこのワークのゴールになる

*むきなおり参考記事

どうやったか

↓のようなスプレッドシートを作成して、全員でこれに書き込んでいくことで実施した

むきなおりテンプレート - Google スプレッドシート

この手のワークショップでは「いっせーの」で自分の意見を出すまでは他の人の考えが見えない方がベターだけど、その点をうまいこと解決する方法は見つけられていないのでこのような形にした

進め方自体は定番通りで、アウトプットのフォーマットがふせんじゃなくてスプレッドシートになっただけ、という形
時間もかかるMTGなのでなるべく簡単に書ける・ツールの使い方で困らないようにしたい・サマる作業を手間を掛けず、と考えたら普段使い慣れてるスプレッドシートを使う、という選択になった

結果どうだったか

割と上手く回ったと思う。チーム的にも有意義だったというFBだった
リモートでのファシリテーションでは表情が見れないので「場の雰囲気」に合わせた調整が出来ないというのはやはり難しいが、もう丸2ヶ月近くフルリモートでチームでの意思疎通をやってきているのもあってか、盛り上がらない(意見が出ない)・場が硬直するといったこともなくスムーズに進んだと思う
自分はずっと対面でやる以外ありえない、ぐらいに思っていたが、リモートでもやれなくもない、ぐらいに意見を変えようとは思った

この時間でチームメンバーの思っていることや普段と違った切り口での課題提起に繋がったし、自分自身開発メンバーとして改めて気付かされたこともあり、単純にむきなおりをしたことによる恩恵もバッチリ受けられたと感じられた

チームとしてもファシリテーターの立場の自分としても、あるいは開発メンバーの一員としての自分としても得るものがあったのでいい時間だったな、という感想
また今度は半期の終わったあとにやろう、という話も出ていて、そのときにチーム・プロダクトがどうなっているかも楽しみ

わたしのコードりれきしょ

他の人が書いてるのを見かけて楽しそうだったのでやってみた


  1. 高校2年生ぐらいの頃にコミケに本を出そうって友達がいてその告知用サイトを作った。(当時友達に内輪用サイト作る人、自分のコンテンツ発信用サイトを作る人などがいてその影響を受けた)。CSS2とかって単語があったのは覚えてる。PHPもHTMLのテンプレートを共通化するために使ったりした。まあつまりサイト制作
  2. 大学の講義でCで二分探索木(なんもおぼえてない
  3. 大学の講義でJavaでなんかのCLI(なんもおぼえてない
  4. 大学の講義でPerl/bashで電卓(なんもおぼえてない
  5. 大学の講義でPHPで就活の何かを管理するためのwebサービス。5人チームで半期かけて死ぬほど苦労した(週50時間ぐらい稼働してたときもあった気がする)。要件定義からリリースまでやるのを半年かけてやる講義できついから覚悟しろよって言われてたけど本当にきつかった。XAMPPでPHP環境作ってやってたけど環境構築死ぬほど大変だし、自分のマシンでは動くのに人の環境では動かない、とか、ソースコード管理がないのでDropbox使ったり、人力マージしたら動かなかったり、あと確か要件定義書のようなやつ(UMLとかも含め)を死ぬほど書いてそれを全部印刷して提出とかしてた気がする。ちょっとした分厚い本ぐらいはあったはず。とか、とにかく辛かった
  6. 研究室でPerlつかってmecab形態素解析したりした。何やったかは全て忘れた、ボスに言われるがままにやっててなんか自分で考えた記憶がない。扱った日本語データがXMLだったんだけど、当時何も知らなかったので正規表現XMLをパースすることを試みてXMLの階層構造を正規表現で扱うのは無理じゃんどうしようもないってなって何かを妥協した記憶はある。DOMTreeにしてvisitorパターン、とか知らなかったからしょうがないね。GitHubに上げてあるけどPrivateにしてあるのでリンクは省略
  7. 就職したてwebの部署に配属されてお問合せフォームをVBScriptで作った。毎月ぐらい定常的にある作業・でも簡単、ということで新人に毎回やらせてるらしい。なるほどかんた・・・いや何もわからん・・・ってなりながら四苦八苦して書いたりしていた気がする
  8. フォームに要素追加する機能をVBSで動いてるサービスに入れるとか、何かの監視機能をVB6で書いたりした記憶はある。この辺何も覚えてない。
  9. なんかの設定画面のリニューアル。先輩がバックエンド、自分がフロントエンドをjQueryで動的にフォームを生成したり消したりするようなのを作った。ここで色々フロントエンドを作るということについて知ることが出来たのが多分フロントエンドエンジニアとしてやっていくことになったはじめの一歩だったと思う。あと今になって思うと、当時SPAとか誰も知らなかったはずだし他の殆どの機能はMPAでVBSのテンプレートの中にロジックがあるっていう昔ながらのPHPみたいなプログラムだったのに、サーバー・フロントを分けてその機能はSPAとして作るってしてたのすごいなあと今書いてて思った。
  10. 9のときに先輩と自分の間でトライアルでgitを使い始めてて、そのgitを社内全体で使おうって活動をしたりした。そのあとバージョン管理やデプロイのフローが破綻してたので、整備してgit使ってpull→デプロイらへんを半自動化する何かを用意した気もする。
  11. 多分C# .NET MVC3のサービスとかにこの辺から入ったりしてた気がする。何作ったかは忘れた。
  12. 他のチームに、200環境に半年かけて手動デプロイするという地獄を観測したのでそのデプロイの自動化ツールを作った。この頃にはjsどっぷりでes6だasync/awaitだみたいなのに染まってたのでランタイムnode0.12.7らへんでbabel使ってダウンパイルみたいなことして作ってた気がする。社内にnode分かる人いなかったし、社内で新しいものについてはC#でやる流れがあったのをガン無視したのは今の自分なら全力で止めそうで笑う(当時の自分はC#CLI作れると思ってなかった(!?)からよくわからないままnodeを選んだ記憶もある)。やってることとしてはFTP繋いでファイルを上げるってだけ。結果デプロイは作業時間としては30分、検証とかその手のバッファみつつ間を空けながら2,3日でやる、というフローで出来るようになった。世界の不幸が一つ減ったことに満足を得たりしていた
  13. 多分11,12くらいの時期からちょこちょこgithubにちょっとしたものを作ってとりあえず上げておく、みたいなことをするようになっていた。sisisin-sandboxというorganizatioを作ってここに何でもかんでもアップしてた。reactやらexpressチュートリアルやったりelectron触ったりexpressで単純なフォームでソーシャルブックマーク出来るみたいなやつを作って自宅のPCをサーバーにしてホストしたりwindows環境用によく使うVagrantfile書いたりwakatimeの実績をtwitterに流すバッチ書いたりアニメ実況向けのtwitterクライアント書いたり何か思いついて形にならないまま放置(何を作ろうとしたのかすら思い出せない)したり、社内向けにgitの勉強会用のgitリポジトリ作ったり、TDDBCで使おうとしたrubyrspec試した形跡があったり、twitterのフォロワーから相談されてtypescriptのユニットテスト環境作ったり色々。
  14. 会社のサーバーサイドがVBSで、その中でVB6で書かれたCOMコンポーネントを利用していて、このCOMコンポーネントを脱却したいという話があった。COMコンポーネントをC#で使う方法があって、これを使ってCOMの機能をC#でラップしてそこを介してどうこうしよう、とか、その機能をマイクロサービス化したら良いんじゃないかとかを調べたり考えたりしてた。とりあえずCOMをC#から動かしてAPIとして呼べるところまでは作ったりはした。活用されることはなかったけど。
  15. 現職に入って最初に試しにscalaでRESTAPIの1エンドポイント作ることになって何もわからなくて詰んだ
  16. typescript+angularjsでダッシュボード画面作った。個人でreact触ったりしてたけどまともなSPAを業務で作るの初めてだったのでかなり苦労した気がする
  17. レポート系の画面を作ったり直したりしてたっぽい
  18. コミティア用にサークルチェック結果をcsvにするスクリプトを書いたりした
  19. なんかよくわからないけどscalaでそこそこ巨大な修正してたっぽい。プルリク眺めてるとほとんどフロントばっかやってたはずなのにどうやってscala書いたんだこの人・・・?
  20. gulpfileがcoffee scriptで書かれてたのをjsにしてgulp-typescriptじゃなくてtsc直たたきにしてパフォーマンス改善したりみたいなことやってた
  21. Angular2が出る出ないみたいな話で試したりとかしてたはず。新規サービス立ち上げのときにRCだからって使っていいでしょって選んだら思ったよりぶっ壊れでごめんになったりもした
  22. 広告計測サービスの計測タグのe2eテストがやたら落ちてるとかの対応したりカバレッジ出せるようにしたりしてたっぽい
  23. tscのoutFileでconcatしてたangularjsのビルドをes modulesに置き換えたりした。tsのcompiler apiつかってast走査してimport文を生成・挿入するスクリプトを書いてゴリッと置き換えたりした
  24. tsdという型定義パッケージ管理ツールを撲滅してた。typingsに飛びつかないでnpmに集約されてからやってるの偉いってなってる
  25. プロジェクト共通で使ってるURL基底クラス部分が広告の計測サーバーやその他諸々で問題があったので置き換えるみたいなことやったらしい。このへんでURLエンコードとはってなって書いた気がするこの記事、未だにちょこちょこLGTM付くので良かったなとか思う
  26. coffee scriptで書かれてた計測タグのe2eテストをjs化したり、会社の納会で1人ハッカソンしてユニットテスト側もjs化したりしている
  27. コミティアコミケの予定をスクレイピングしてGoogleカレンダーに入れるバッチ書いた
  28. 次の日の予定に気づかずに寝坊遅刻みたいなのがちょこちょこあったのでGoogleカレンダーの次の日の最初の予定を取ってきてtwitterでメンション飛ばす機能を作った。マジで便利だった
  29. SafariのITPが来たのでその対応のために計測サーバーや計測タグの対応をしたりしていた。どうやってcookieつければいいかとか1st cookie使ってどうこうとかタグの発火順とかを設計したりして大変だった
  30. 開発合宿で広告計測サービスの管理者用画面のAngular化を7割ぐらいやった。楽しかった。
  31. CI職人やってるっぽい。フロントのみの変更のときにscala系のタスクが走ると厄介なので直したり、CIで使ってるDynamoDBとかのイメージを差し替えたりscalaの本番用ビルドをS3に上げる部分いじったりscalaのCIパフォ改とかいろいろ。
  32. 広告計測の集計結果をs3->gcs->bqと突っ込むようにする作業をしたりしていた。s3 to gcsでtransferサービス使うときにファイル数が多すぎて不安定になって障害起きたりして大変だった
  33. cloudfirmation触る機会が増えたりしてcloudformを試したり、cloudformに機能追加したりした
  34. react/reduxのプロダクトを立ち上げたりしていた
  35. storybook+reg-suitの環境作ったりしてビジュアルリグレッションテストを搭載
  36. 開発合宿でslackをtwitterふうに閲覧できるクライアントを作ったりした。これもreact/redux。サーバーはexpress
  37. 蔵書管理アプリtypelessで作った。スマホカメラでバーコード読んで借りる返すができるようなやつ
  38. typelessに色々コントリビュートした。型定義怪しいの直したり、バグっぽい挙動の修正方法提案したり、middleware実装しやすくする方法を作ったり、RegistryやEpicのユニットテストしやすくしたり、EpicでPromise受け付けるようにしたり
  39. typeless触ってて見つけたtypescriptのLanguageServiceのバグを直した
  40. railsで集計処理っぽいクエリを書いて地獄を味わう
  41. railsで重いクエリと戦い敗北してredisにキャッシュすることで逃げたりした
  42. mackerelの監視環境を整えたりした
  43. railsのバッチでメモリプロファイラ使ったりして重い処理を探して直したり
  44. react-routerで型安全にroute定義出来るように試みた
  45. grqphql叩くやつ書いたりしている

細かく書いてたら長くなってしまった

ISUCON9予選参加した

反省会。

チームについて

@kadokusei , @watiko と3人で sisisinと愉快な仲間たち チームとして参加。
kadokusei がインフラ、 watiko・自分がアプリとかボトルネック調査を担当

自分の覚えてる範囲でやったこととか書き残しておきます

最終的に出来たこと

  • /users/transaction.json の外部API呼び出しのキャッシュ
    • redisに /status の結果をキャッシュしておいてそこから引く処理を入れた
    • /initialize 時に初期データから取得できるステータスを全てキャッシュに突っ込んだ
  • DBインスタンスを分けた・DBインスタンスにredisを載せた
  • categories テーブルのデータをメモリにキャッシュ
    • 最初から全部乗せるのはテーブル構造が地味に複雑だったので諦めて、結果をメモ化するにとどめた
  • items,transaction_evidences,shippingsに適当にインデックスをはった

やろうとしたけどダメだったこと

  • appの複数台構成
    • 画像をwebdavで一台にまとめて置く、などを試すも、アプリからwebdavにファイルを置くのが上手く行かず断念
  • /users/transaction.json の外部API呼び出しの並列化
    • こんなに言語によって難易度差出るやつは想定解法じゃないんじゃ?って疑問に思ってドキュメント見たらキャッシュできそうだったので方針切り替えた

調べて気付いたこと

  • datadog APM使って各種エンドポイントとそのどこに時間がかかっているかの調査
    • /users/transaction.json , /items/:item_id.json , /new_items.json 辺りが重い
  • DB全然時間かかってなさそう
  • /users/transaction.json はN+1に目がいったけど実際はAPI呼び出しがめっちゃ時間食っている
  • categoriesusers テーブルの呼び出し回数がやたら多い(が、時間はかかってない)

つらかったこと

  • 初手アリババクラウドから身分証明書提出を求められるダイアログが出てしまって運営の対応待ち。
    • 10:30ぐらいまで何もすることがなかったのでマニュアルを読んでいた。
    • せめて /docs だけでも最初に配布しておいてもらえればまだ良かったんだけど・・・

  • デプロイ周り整えるのに時間食いすぎた

よかったこと

  • 準備してたところはちゃんと出来た
    • redis用意、datadog apm用意、初期のconfig作成など
  • ローカル環境整えたのは便利に活用できた人もいた(自分は /users/transaction.json の動かし方がわからなかったのであまり活用できず。。)

感想

最終的に目の付け所は悪くなかったと思ってるんだけど、自分の地力不足を感じた
たかがインデックス貼るスクリプト書くのに30分とかかけてて雑魚乙って感じになってしまった、もっと上手くなりたい・・・

あとデプロイ周りは書いて終わりじゃなくてデプロイしてベンチするところまでちゃんとやりたいとか、ボトルネック調査もっと上手くやりたいとか色々ありつつ

初参加だったけど手応えはあった気もする
ただちょっと微妙な点として、普段こんなに生のインスタンス触らないから練習負荷が高いのがなんともなあという気持ちがちょっとだけあったりも。

結構悔しいので来年もまた頑張りたい所存

Aurora ServerlessとECS Fargateで動くRailsアプリのクエリチューニングをした

tl; dr

  • Aurora Serverlessの場合はスロークエリログ有効化設定がAWS上にある
  • DataAPIを有効化すればクエリ叩き放題で最高
  • チューニングのためのはじめの一歩として、パフォーマンス計測のための環境整備をインフラやアプリに合わせて適宜構築するのが大事

結果としてやったことはただ単純にslow query logを有効化して該当のクエリをexplainして直しただけ

前提

アプリケーションサーバ

DB

  • Aurora Serverless
  • MySQL 5.6

インフラの構成管理にはAWS CDK経由でCloudFormationを利用

準備

まずスロークエリログを見たい or APMでアプリのボトルネックを見たい、というところからスタート
スロークエリログ有効化の方が手っ取り早いし多分クエリが遅いはずだと思ってたのでひとまずスロークエリログから着手した

スロークエリログ有効化

Aurora Serverlessを利用している関係で直接MySQLのログを見ることは出来ない
CloudWatchLogsに吐かせる設定がコンソールやCFnなどから出来るのでその設定をした

参考:

Aurora ServerlessでログをCloudWatch Logsへ出力可能になりました | DevelopersIO

*aws-cdk@0.20.0 を利用(古いのはご愛嬌)

const dbParameterGroup = new rds.ClusterParameterGroup(this, 'DBParameterGroup', {
      family: 'aurora5.6',
      description: `Parameter Groups`,
      parameters: {
        slow_query_log: 1,
      },
    });
    const cluster = new rds.cloudformation.DBClusterResource(this, 'Database', {
      dbClusterParameterGroupName: dbParameterGroup.parameterGroupName,
      // 中略
    });

スロークエリログで何度も叩かれてそうな上に遅いクエリを見つけたのでとりあえずそいつをexplainしたいということになったので今度はその準備をすることに。

DBインスタンスにクエリを実行する

結論としては、Aurora ServerlessのDataAPIを有効化してAWSコンソールから直接クエリできるQueryEditorを利用した
参考: Amazon Aurora ServerlessでManagement Consoleからクエリが実行可能になりました | DevelopersIO

他の選択肢はこんな感じだった

  • ecs-cliのrunコマンド経由でrails runnerを利用してモデルのクエリをexplainする
    • ECSタスクを毎回立ち上げてクエリしてその結果をCloudWatchLogsで確認、という流れなので死ぬほど面倒
  • gatewayサーバー立ててssh
    • EC2立てるだけっちゃだけだけど、その辺手慣れてるメンバーがチームにいないので微妙に腰が重かったしお金もかかる
  • ALBで一時的にVPCトンネルをつくる・・・?
    • 風のうわさでそういうことが出来ると聞いたけどよくわからなかった

結果

ここまででスロークエリを探してexplain出来るようになったので、該当のクエリを見てみたらwhereされてないサブクエリの結果セットが80万行とかになっていたのが原因ということが判明
適当にモデルのクエリを調整していい感じに速くなった。めでたしめでたし。

APMについて

チューニングしたときには活用しなかったけどちょろっと調べたり動かしたりしたので一応メモ

あがった選択肢

  • NewRelic
    • gem入れるだけで動かせてお手軽
    • ECSの料金体系についてドキュメントがなく、問い合わせて見積もりもらわないとわからないので会社員的に地味に辛め
      • *そのぐらいポンッと使わせてくれない会社が悪いという説もある
  • AWS X-Ray
    • ECSの場合エージェント用のタスクを立ち上げる必要があるのでNewRelicに比べると導入めんどい
    • ドキュメントにもRailsのサンプルがなく、多少試行錯誤しそうだったので動かして見るところまではまだやってない
  • DataDog APM
    • NewRelicよりは安そうだった
    • あまりちゃんと調べてない

感想

Aurora Serverlessが便利だった(こなみかん)


実はこのクエリチューニングはチームで1日時間をとってISUCON大会と称して合宿したときの成果で、それはそれで良かったという話もあったり。
スロークエリを探しつつAPMをアプリ得意な人が準備したり、explainするときに何見ればいいのかとか横からアドバイスもらったりしながらワイワイやれて楽しかった。

うちのチームは様々な事情でバックエンドエンジニア不足のためにこの手のタスクの進みが悪いので、こうやってISUCON大会してガッと進められたのはめっちゃよかった

6月の新刊が多すぎるのでメモる

amzn.to amzn.to amzn.to amzn.to amzn.to うちの娘の為ならば、俺はもしかしたら魔王も倒せるかもしれない。 5
トニカクカワイイ(6)
私に天使が舞い降りた!6
君に愛されて痛かった(3)
ブルーピリオド(5)
舞妓さんちのまかないさん (10)
ダーウィンズゲーム(18)
初恋ゾンビ (17)

scansnapでスキャンした画像を自前で用意したプログラムで処理する

tl;dr

  • 連携するアプリケーションという設定 で、1回の取り込みが終わったタイミングで呼び出すexeファイルを指定できる
  • exeファイルは読み込んだファイルのファイルパスをコマンドライン引数で一括で渡してくれる
  • なので、コマンドライン引数を処理するプログラムをexeファイルとして固めることができれば自前のプログラムで自由に触ることができる

ということをやるプログラムを書いた

github.com

やったこと

  • nodeのプログラムをexeに固めるビルド環境の整備
  • Macでの開発環境作った
  • Windows環境のexeファイル呼び出しあれこれを調整

nodeのプログラムをexeに固めるビルド環境の整備

  • nexe をつかうだけ
  • Windows環境下で使う場合、Windowsでnexeを実行すれば何も考えずにexeファイルが作れる

Macでの開発環境作った

Windows環境でnode書くのいろいろしんどい(Macキーバインド違う、win周り疎いのでターミナル環境でハマる(素でnpx使えないのビビった))ので、Macで開発できるようにした

  • nexeの引数でwindows向けビルドを出来るように
    • -t win32-x86-10.13.0 で動いた
    • が、 win32-x86-10.13.0が何を指すのか全くわかってなくて辛い
  • バイナリをDropboxに吐き出すように調整
  • 基本的な動作確認はエントリポイントのファイルを nodeで叩けば良いので特に考える必要がない

Windows環境のexeファイル呼び出しあれこれを調整

  • PATH設定して再起動
  • exeファイル呼び出しで何もしないと実行が終わり次第ターミナルが落ちるので、readline.createInterfaceで待ち受けるようにしたり、ログをファイルに落とせるようにしたり

Macの環境作るのに一番ハマったので、我慢してwin環境で書けばよかったかも。。
やること自体はただのファイルコピーみたいなもんだし

やろうと思ってやらなかったこと

  • バイナリ公開
    • 誰得感あったのでやめた
    • cloneしてビルドコマンド叩いてもらえれば使えるしまあええやろみたいな気分
  • 対話インターフェース作って保存先調整したりしよう
    • 取り込み作業がめんどくなるのでやらんでいいかなと言う気持ちに
  • テスト・CI
    • travisがwin環境提供し始めたらしいし、exeビルドしてe2eテストとか書くと安心感あるかなと思ったけどめんどくさくて未着手
    • readline で待ち受けるところとかがね・・・
    • 気が向いたらやるかも?

SlackをTwitterのタイムラインライクに閲覧できるクライアントを作った

予定だったけどちゃんと作れた。やったぜ。
感想っぽい内容なのでQiitaではなくブログにしといた
というわけで簡単に振り返り

続きを読む