技術へのこだわりとプロダクトを作り上げるバランスを忘れない
この記事はmast Another Advent Calendar 2018の19日目の記事です.
18日目は同級生kawaguchikoくんの記事でした.彼の記事おもろいので読んでみてください.
mast15の @chigichan24 です.四年生ですが,大学は二年目です.のらりくらりとプログラムを書いて遊んでいたらこんな感じになりました.mast15では自称プログラムが書けるマンとしてイキってます(ごめんなさい)
さて,いろいろと書きたいことを迷いました.迷ったけどこれにしました.理由はmastの人の多くは,ものづくりやメディア表現等を通して社会になんらかのメッセージを残すことを試みる集団であるからです.
技術へのこだわりとプロダクトを(ry
この言葉は私自身が,ものづくりをする上で大切にしている言葉です.(以前は「まずは手を動かしてみる」という言葉が好きでした)
誰かの偉人の言葉とかではたぶんないと思われます.このワードでぐぐってみる*1と,私のTwitterアカウントやWantedlyプロフールが見つかります.多分私が産み出した言葉なんだと思います.
さて,この言葉前半パート(1),後半パート(2)そして,結合パート(3)によって成り立っています.それぞれ分解して,解説していきましょう.
(1) 技術へのこだわり
私にはソフトウェアエンジニアとしての経験しかないため,ソフトウェアエンジニアが関係する「技術」についてのみ話すことにします.
一般論ではなく,個人的な見解として,程度の差はあれ多くのソフトウェアエンジニアはこだわりを持っています.
例えば,どの言語で開発を進めるのか?という議題.
PHPでしか経験がないから〜*2という人もいれば,スクリプト言語っぽいもので〜という人,今回は型をちゃんと使って〜とか,今Rustがキテるっぽいらしいよとかいろんなこだわりがあると思う.そのこだわりには
- 純粋なる知的欲求からくる希望
- 様々な開発現場で使ってきた経験からくる推し
- このほうが最新の規格だから,いろんな機能が使える
などなど様々.みんな技術に対して誇りや欲求をもって生きてます.
言語がやっと決まったら次は使うフレームワーク,使いたいアーキテクチャ,開発手法,CI/CDは回すの?レビューの進め方は?コーディングの規約は?使うIDEは?と言っていろんな決めごとに対して,開発するチーム(または個人)で同じようにこだわりを議論していきます.
(2) プロダクトを作り上げる
プロダクトには納期があるものがあります.納期は,学生のうちであればコンテストの締切とか,インターンシップでの期限とか,自分の熱が冷めないまでとかです.
納期までにものを作り上げることは,ものづくりをする上で常に付き纏います.完成させない状態でやっぱりだめでした😪と芸で済ませることも経験の一つです.*3
しかし,その質を客観的に見たときにどの程度まで詰められているのか?というのも求められる機会は多いです.会社に入ってソフトウェアエンジニアとして開発をしているならば,それは絶対的なものに近しいです.
これを達成するには入念なスケジューリングと進捗確認が大切です.これらを適切に管理できていれば,やっぱり駄目でしたとなることは少ないはずです.なぜならば見通しをある程度立てて計画をするため,このままだとまずいスケジュール感だとわかるはずだから.
(3) バランスを忘れない
これは(1)と(2) の取捨選択を適切に行いましょうというものです.
例えば,究極にスケジュールに余裕がない状態で絶対に使い捨てのプロダクトを作り上げないといけない状況があったとしましょう.こんなときに新しい言語で挑戦的にプログラムを作っていくことができるでしょうか?
答えはNoです.
実績のある言語を使って突貫的にでも完成を優先するべき.つまり,この場合は(2)の「プロダクトを作り上げる」を優先するべきということです.
他の例として,長期的に保守していく必要があるプロダクトを作る時,また,メンバーが新しく追加されるケースも多いとしましょう.品質も,多くのユーザがいるので高く保つ必要があるとしましょう.
このときに,上記のように突貫で作っていいでしょうか?
答えはNoです.
この場合は長期的に保守していける体制を保つために,どういった言語であれば良くて,どのようなアーキテクチャであればバグが少なく,また発生しても容易に特定できるか?を意識する必要があります.
現実の問題は上の2つの例のように単純ではありません.しかし,根本にあるのは技術をどう使っていくのか?どこまでこだわるのか?ということのはずです.
自分の立場を明確にする
さて,上の議論は「自分自身がものづくりに対してどういう気持ちで向き合っているか?」を考える上でも役に立ちます.
ちょうど式にするならば 0 ≦ α ≦ 1とするときに,
自分のお気持ち = α × 技術へのこだわり+ (1-α) × プロダクトへのこだわり
といった形で表わされる事ができます.
この言葉が自分の中で生まれた背景として「プログラミングは手段か?目的か?」という議論があります.
昔,特に高専時代は,私は絶対的にプログラミングは手段でしか無いと思っていました.けれど,プログラムそのものを学ぶうちにソフトウェアエンジニアであるならこれは目的であるべきだとも思うようにもなりました.
しかし,この議論自体0,1でどちらかの表明をする事はできない.時としてどちらかを優先するべきだなぁといろんなプロジェクトでコードを書いていくうちに思うようになりました.その上で,自分のマインドはαがだいたいこの辺りだと表明していくことが大事だという結論で,自分の中では決着がついています.*4
おわりに
今日は私がソフトウェアエンジニアとして,大事にしている言葉の紹介と詳解でした.みなさんも,ぜひ意識してみてはいかがでしょう?また,上の式の訂正や議論などもぜひ...
それでは.
退職しました😭😭😭
退職エントリです(この文言を書いてみたかっただけ).7ヶ月くらい長期インターンシップとしてお世話になった株式会社Moffを退職しました.
先に書いておくと,辞めた理由は,研究活動が本格的に忙しくなりそうというのと,任されていたタスクがある程度区切りが見えたからです.負の感情で退職したわけではないので,勘違いしないでよね[^1].
今回の記事ではどれだけお世話になって,この半年でどれだけ強くなれたかを
- 技術的側面
- 技術以外でいろいろ感じたこと
の二本立てで書いていこうと思います.長いです.長いので以下の目次で興味のあるトピックを読むことを推奨します.当然ちぎちゃんのファンの方は全部読むと良いです(?)
- 馴れ初め
- 技術的にやったこと
- やったこと概要
- 技術要素
- SDK改良
- データ蓄積・分析基盤構築
- IoT機器接続基盤の設計・実験的実装
- 技術以外に感じたこと
- メンター編
- 会社の雰囲気編
- 今後
ISUCON8予選で負けました
ISUCON8予選に@k5342と @euglena1215 とでて惨敗しました.さようなら.
ふたりの記事は(特にk5342のほうには)詳細に書いてあるので,そちらを参考にするとムーブがよくわかります.ありがとうk5342メンバー!
なんか二人がいろいろ書いているので私はポエムを書こうと思います.
ポエム
nginx 最適化設定編
nginxとは,紛れもなくweb サーバであるが,単にエンドポイント振り分け係としての機能に加えて,同時にロードバランシングができたり,sessionを保存しているノードに振分けることができたりとそれなりに有能なのである.似たような機能を持つものとして,Apacheやh2oがある.これらのチューニングのうち,Apacheのみは経験したことはあったが,h2oはデフォルトではやい*1 らしくまともにチューニングしたことはなかった.なにより,デフォルトのh2oはデフォルトのnginxよりは当然性能はいいが,高度にチューニングされたnginxはh2oと同等もしくはそれ以上の性能を引き出せると未だに考えている.
ところで,今回のISUCONの初期実装ではh2oであった./etc/nginx
がないというのはかなりの衝撃であった.が,未だにh2oであったその真意はわかっていない.それでも上記の理由に加えて,不慣れなものはとっとと切り出すほうがそこに時間を食わなくて済むという経験に基づいて開始早々引き剥がす決断をした.
nginxの最適化というのはアプリケーションの実装によってどのパラメータを変更するのか,様々な使用率状況を把握しながらある程度は自動的に,それ以降は職人の勘で行っている.無闇矢鱈に様々なパラメータを on
にすることは避けたほうがいいというのがここ数年 nginx調整係*2としての勘である.
それを踏まえて今回のISUCONを振り返ってみるとあまりにも勘に頼りすぎた可能性がある.例えば,今回の問題のアプリケーションやDBのCPU使用率はそれなりに高く,またそれ以上にメモリの使用率が半端なかったので,gzip周りで最適化することはこれ以上にサーバーに負荷を掛けてしまう恐れがあるため今回は見送った.また,最低限静的ファイルのキャッシュは終わらせたがそれ以上のチューニングは難しいと判断して早々に放置してしまった.いま考えるともっとチューニングバトルをしても良かったかなと思う.ということが複数個あって,「やらないで後悔するくらいならやって後悔したかった」という感じだ.去年のような画像がそれなりにある問題でCache-Control
をつけると脳汁がドパとでるほどにスコアが跳ね上がる傾向にあるが,今回みたいなタイプはどうしてもスコアが上がりにくいし,しんどすぎという感じだった.
一方で,早々に切り上げる判断ができたのは良かったと思える面もある.それは明らかにnginxよりもmysqlの設定を更新したほうがスコアが上昇する状況だったので,小手先のスコアを伸ばすくらいならアプリケーションが大量のN+1
問題やN*(N+1)
問題(多重にN+1問題を起こしている)のようなDBへの負荷を爆上がりさせてくれるような問題を抱えていたのでnginxに時間割かなくてよかったとも言える.
mysql最適設定編
mysqlのチューニングとなるとinnodb_buffer_pool_size
をいじるだけでしょ(笑)みたいなことを言われるが(言われたことはない),それ以外にもデフォルトだとそれなりに低く設定されているため改変するべきものは多くある.
しかし,今回の問題では上で書いたとおり,DBのCPU負荷,メモリ負荷が尋常ではない状況でメモリキャッシュさせるのはどう考えても悪手であるという感じだったので,max_connections
を増やす程度の設定しかできなかった.
ただ,複数台構成が実現できそうになるとDB単体で一つのサーバが与えられ,それなりにメモリに余裕ができてきたのでそのような設定を入れることができたのは良かったと思う.
ここまで書いていて
ここまで書いていて,今回のISUCONは昨年のISUCON本選同様に,最適設定ゲーではないというのがわかる.つまりアプリケーションをなんとかしないと話にならない.という話だ.
ペアプロ編
例のget_events
クエリ潰し大会で三人でペアプロしたのが良かったのか悪かったのか問題はメンバーの間でも様々であるが,結果的には成功だったけど明らかに時間を掛けすぎた.あれに関してはてっぺーさんを信じるのと,値を見間違わないようにしないといけないという感じ.うーん.悲しい.
report_for_sales重い問題編
これは重い.おもすぎて60秒以内にレスポンスが入ればみたいなレギュレーション *3 である時点で明らかにやばいオーラを放っている.こいつがそれなりに重いためメモリ食ってんじゃないかという話になり私が担当した.sqlが3つのテーブルをinner join
するような形を取っていて,ほぼすべてのスキーマを参照してそれを一度ハッシュにぶち込んで,それをソートして渡して文字列を生成してcsvにするという形を取っていた.
この問題に当たる頃にはとにかくアプリケーションのCPU使用率とメモリ使用率を下げろ!という指示だった.
まず問題としてありえん巨大なsqlを改善したいとなったが,これをチューニングするのは死ぬほどつらそうと思った.次にわざわざメモリに展開してからソートするのは馬鹿らしいのでsqlでORDER BY
すればいいと思った.よく確認するとsqlですでにソートされているのに再度ソートを掛けていて :thinking_face: となったのでその処理を外した.また,わざわざハッシュにする意味もないので直接文字列生成してそれをrender するみたいな方針にした.
この効果は不明だが微妙にスワップが減ったが微々たるもの(k5342談)だったので,うーん辛い.
総括
多分,負の貢献をしてしまったのでつらい.お茶くみすればよかった.なによりRubyチームにのみ多く見られた例の問題は言語的な辛さなのかなぁと他のチームの話を聞く感じ思った.また,salesのところだけエンドポイントを切って別サーバに任せるという技がまじですごいなと感心した.すごい.
最終スコア
これでは顔採用は厳しいです.
リポジトリ
謝辞
WantedlyオフィスでISUCONに参加させていただきました.まじでありがとうございました.ディスプレイ借りれたり,ホワイトボードを借りれたり,テレビ借りれたり,椅子(いいやつ)を借りれたり,助かりました.あとオフィスが綺麗でした.
また,去年と同じメンバーで今年も参戦することができて非常によかったです.かなりバランスの取れたチームであったので本当に本選に駒を進めたかったです.来年も @euglena1215が電撃で留年か大学院に進学することで学生枠で出たいです(冗談です)