ソフトウェア・ファースト あらゆるビジネスを一変させる最強戦略の読書メモ
及川卓也さん著のソフトウェア・ファーストを読んでみたので、その読書メモ
はじめに
IT業界、エンジニア業界で著名な及川さんが書かれた本ということで存在は知っていたので、本屋に立ち寄った際に目次をパラーっとみて見たところ、 「ソフトウェア・ファースト」とは何を指しているのか?また、「ソフトウェア・ファーストなキャリア」という見出しや章が気になったので購入し、読んでみました。
読書メモ
前半
ソフトウェア・ファーストとは
前半はソフトウェア・ファーストとは、から始まり、
ITやソフトウェアにおいての日本とそれを取り巻く世界の現状と課題、 そして、その課題に対して必要な変革について述べられていました。
以前の主流であったパッケージ型のソフトウェアではなく、 近年はSaaSなどによる産業のサービス化が主流となり、これまでとは開発の進め方やビジネス、サービスの考え方が大きく変わって来ている。
それに対応するためにIT活用やソフトウェアを核として課題解決をし、事業や開発を進めていく考え方がソフトウェア・ファーストとのこと。
日本が抱える課題とは
日本と欧米ではソフトウェアに対する考え方や関わり方があり、日本ではイノベーティブな開発が行いづらい側面がありそう。
日本は品質に対しての意識は高く、これまで製造業で培ってきたものがある。
「狩野モデル」を利用して、開発するソフトウェアやサービスに求められる品質を正しく定義することで、このような課題を解決していけるかもしれない。
あれば満足だが、無くても仕方ないと思われるような「魅力品質」がイノベーティブなプロダクト開発に繋がっていく。
今まではユーザーが欲しい物を作っていた時代だったが、今後はユーザーが欲しいものを見つけていく時代に移り変わってきているので、 時代の変化に合わせて考え方や開発の進め方なども変化や進化が必要。
後半
エンジニアのキャリアについて
後半はソフトウェア・ファーストな組織キャリア
キャリアパスについては前職や今の職場などでも同様のロールやポジションがあるため、個人的にはその定義の再確認といった部分が多かった。
ただ、近年よく聞くがイマイチ分かっていなかったエンジニアリングマネージャーのロールや、テックリードとの違いについてはこの本を通して何となく掴めた気がする。
しかし、結局は会社・組織毎に肩書とロールが異なってくる部分もあると思うので、あくまでも目安、参考情報として踏まえつつ、それぞれの文脈や組織によっての変換は引き続き必要なのだろうと思う。
及川さんのこれまでのキャリアについて
また、後半でとても興味深かったのは、及川さん自身のいままでのキャリアでのターニングポイントと、その時々に感じていたことなどがまとまっていた部分。
第一線で数々の経験をされてきた方の今までの変遷や足跡を辿ることで、 誰もがぶつかるであろう悩みや課題を同様に抱えていること、またそこに対してどのようなアプローチ、行動をしてきたのかということは今後の参考しつつ、今までの自分に足りなかったこと、今後必要なことの見直しにも繋げていければと思った。
全体を通して
まだまだ、うまく自分事に落とし込めていない部分などもあるので、時間を置いてまた読みつつ、自分が置かれている状況や今後の自分のキャリアやエンジニアとしての生き方について考えたいと思いました。
Kyash Meetup #7に参加してきました
Kyash Meetup #7
We are Kyash Direct 2019/11/14@Kyash
KyashさんのMeetupに参加させていただいたのでそのメモ。 最初にCTOの方からKyashやKyash Directについての説明があり、その後、各エンジニアのLTセッションがあって最後に懇親会という流れだった
LT 1 : Welcome to Kyash! by 椎野 孝弘さん
- KyashDirectのエンジニアは4人
- 全員サーバサイドエンジニアでフロントエンド専任はいないとのこと
- ビジョンは価値移動のインフラを作る
- お店や人々、そしてお金などの移動をスムーズに行うことでよりよい世の中にしていく?
- これまでの主な歩み
Kyash Directとは?
Kyashの特徴
- イシュイング
- Visaカード発行ライセンス、前払い式支払い手段を取得
- プロセッシング(決済処理)
- アプリケーション
- イシュイング
Kyashの今後の展開
LT 2 : 知識0からはじめる決済処理 by 松雪 俊さん
カード決済について
- 請求的なことはクリアリング(売上確定)という ※その他カード決済に関わる用語、事業の概略について説明されていました
アーキテクチャ
- DDD(clean architcture) & MicroService
- 各マイクロサービスはMessageBusで結合
- sagaによる補償トランザクションで一貫性を確保
質問であがった内容
LT 3 : サーバーサイドエンジニア集団のためのElm by 鈴木 亮太さん
- 管理画面について(Elm製)
- Elmは静的型付け関数型のJS
- アーキテクチャ
- TEA(Model -render-> View -message-> Update ---> Model)
- Elmのメリット -> 考えることが減る。サーバサイドエンジニアばかりのKyash向き(フロントエンジニアはいない)
- Kyashでもtech lunchがあるらしい
LT 4 : 入門Certificate Transparency by 村上 孝則さん
質問で上がった内容
- なぜ".co"なの?
- kayash.comはすでにインドの会社に取得されていて使えなかったため
懇親会
サービス設計について
- 法律や専門知識など関わってくるところもあるのでリーガルやエンジニアなどみんなでわっと集まって話したりしているのか?
- そういうフェーズもある
- 最初のフェーズではマネージャーなどが集まって決めている? ※ここよく分からなかった・・
- 法律などはかなり専門的な知識が必要になるので、その辺りはもちろん気を払って対応している
- そういうフェーズもある
- 法律や専門知識など関わってくるところもあるのでリーガルやエンジニアなどみんなでわっと集まって話したりしているのか?
インフラ
- AWSを使っている。現状はKuberntesマネージドなどは使っていないとのこと
- KyashDirectの開始でだいぶ収益も上がってきた
- 歴の浅いメンバーも多い中で情報やドメイン知識などのナレッジ共有はどうやっている
- 入社前の推薦図書があり、入社前にそこで最低限の知識はためておく
- 人数も少なく風通しも良いため気軽に質問できる雰囲気がある
- ドキュメントなどが整備されていないため、新規のメンバーなどがドキュメント化などのアウトプットをしつつ学んでいく
- その他
- 当日の参加者には入社予定の方やカジュアル面談を経て参加されている方もいた様子
- 大半のエンジニアがここ1〜2年以内に入社されたメンバー
感想など
まずはオフィスが意外にもオープンな雰囲気があり、当初のイメージや金融周りの事業のイメージとだいぶ違った感じのオフィス、組織だなと感じた。 また、今回の登壇者の方々は全員、入社半年以内ということだったが事業やサービス、決済に関する知識をしっかり持たれていて、技術力だけではないエンジニアが揃っているのだなという印象を強く感じた。 それと同時に、メンバー皆Kyashのサービス愛もすごく感じて良い雰囲気の会社、チームだなというのも伝わってきました。 その影響もあってか懇親会もとてもフランクで話しやすい雰囲気でLT含めてとても良い時間を過ごさせていただくことができました。
LTのアーキテクチャの話が今回は一番興味がある話だったので、DDD+マイクロサービスを使っていることやSagaパターンを利用していることが知れた一方で、 モデリングや設計、運用についての話ももっと聞きたかったなというのが心残りでしたが、とても良い機会でした。ありがとうございました!
CODE COMPLTE 第1章 読書メモ
背景
ソフトウェア開発に携わるものとして読んでおくべき名著としてよく名前のあがるCODE COMPLETE。 上下巻揃えたものの、今ままでかいつまんで一部分読む程度で「ちゃんと読んだ」と言える状態になかったので、あと2ヶ月弱となった今年中に気になった箇所だけでも、しっかり読んでおこうと思い立ち、読み進めるとともに、後から見返したりできるようにちょっとしたメモがわりにこちらに書きました。
読書メモ
1.ソフトウェアコンストラクション
ソフトウェア開発の大部分を占める、開発の中心的なアクティビティのこと。どのプロジェクトでも必ず実行される唯一のアクティビティ。
コンストラクションのほとんどの部分はコーディングとデバッグだが、設計や計画、テストといったアクティビティも含まれる
コンストラクションは機械的なものでなく、創造力と判断力を必要とする
結果として、コンストラクションの方法をどれだけ理解しているかが、どれだけ優秀なプログラマであるかを決める。
2.ソフトウェア開発への理解を深めるメタファ
よく理解できないものをよく理解できるものと照らし合わせた結果、何かがひらめいて、解明できなかったテーマへの理解が深まることがある。メタファのこうした利用を「モデリング」と呼ぶ
メタファは、ソフトウェア開発プロセスを既知のアクティビティと関連づけることでその理解を促進する。
メタファをどれだけ理解できるかによって、ソフトウェア開発をどれだけ理解できるかが決まる
ソフトウェアメタファは「アルゴリズム」というよりも、「ヒューリスティクス(発見的)」という意味合いが強い。見つける方法を教えるだけで、何を見つけるのかは教えてくれない。 答えを見つけるために役立つテクニックの一つ。
ソフトウェアに関するメタファには様々なものがあるので、目的にあったメタファを組み合わせて利用すれば良い。
3.上流工程の必要性
プロジェクトの成功の行方は、コンストラクションが始まる前に大方決まってしまう。 コントラクションの前の下準備である、アーキテクチャ、設計、プロジェクト計画といった上流工程が大事。
準備が不十分になる一般的な原因は、上流の作業を担当する開発者が、与えられた仕事をこなすための専門知識を持っていないことである
準備を事前にどの程度まで完了しておくかについては、ソフトウェアの種類、プロジェクトの形式、技術的な環境、スタッフのスキル、プロジェクトの目標によって異なる。 大抵のプロジェクトは高い反復性を必要とするが、プロジェクトによっては逐次性を重視する場合もある
課題定義が十分でないと、コンストラクションの際に解決すべき課題ではなく、誤った課題を解決する羽目になる
要求の策定が十分でないと、課題の重要な特徴を見逃してしまう恐れがある。
アーキテクチャの設計が十分でないと、コンストラクションの際に解決すべき課題はあっていても、誤った方法で解決する羽目になる
プロジェクトにおいて、コンストラクションの準備がどのように行われたかを理解し、それに応じてコンストラクションのアプローチを選択する
4.コンストラクションの重要な決断
第1章の振り返り
ソフトウェアコンストラクションという、開発の大部分を占める作業についての定義や、それに関わる準備から実践までの作業の必要性、重要性について説いている部分で、 自分の感想や感覚としては、今までやってきたことや、ソフトウェア、サービス開発とはこういうものだというのが丁寧に整理され、言語化されていたのがこの章だと感じた。
アーキテクチャの部分については、自分は基本的にwebサービスしか携わってこなかったため他の分野ではこういうところに着眼するのかということが、ざっと見レベルだが垣間見れたように感じた。
1章の中では、自分は特に「メタファ」についての箇所はとても興味深かかったと感じた。 最近、思考法についてやDDDについての本を読むことが多く、どちらでも必要かつ重要な概念・スキルとして「抽象化」が取り上げられていたが、その抽象化を行う過程で必要となるのが「メタファ」であると考えている。
特に本書で、ソフトウェアのメタファについて、「ヒューリスティクス(発見的)」であるとされている点については、なるほどと思わされた。 今まで、何かしらの「答え」を探して「答え合わせ」をするようになってしまっていた部分が多く、 何かが違う、うまくいかない、と感じていた部分が、この言葉ではっきりしてきたように感じられた。
もちろん、ここが言語化されてクリアになったところですぐに何かが改善できるわけではないと思うが、今後はこの勘違いの沼に今後ハマらず開発を進めていくきっかけにはなりそうだと思う
今は次の2章を読んでいるところだが、ボリュームも多く内容もぎっしりなので、いつまとめられるか、そもそもまとめられるのかどうか不安・・
転職して1年が経過したので振り返り part2
現職に転職して約1年経過したのでその振り返りのPart2 Part1はこちら
2019年1〜10月
仕事面
年が明けて入社して3ヶ月くらい経ったので、少しずつ慣れきたりナレッジも増えてくる一方で、 思ったほど成長や成果を感じることがないなと思って焦り、序盤は朝いろいろ調べながら学んだり、なるべく数多くのタスクをこなそうとしていたように思う。 今振り返ると、自分に必要だったのはもっと1つ1つのことの集中して、その背後や周辺知識などをしっかり固めておくことだったように思うが、 当時は数や幅にこだわり中途半端な感じになってしまっていたように思う。
その後は結婚式の準備などでバタバタし、プライベート優先の期間があったため、そこで少しペース置いた後に、 また元のペースに戻して、今度は仕事の幅やレベルを中心に考えるようになったが、まだまだなんとかこなしている感が拭えず、調整ごともうまくいかないなど反省や後悔することも多い期間を過ごしていたように 今振り返ると感じる。 ただ、この期間の反省やここで焦った結果の行動が少しずつ、改善にはつながっているようにも思うので、もがいた期間もムダではなかったのかなと思っているし、そう願いたい。
また、仕事とはちょっと離れるが、9月には職場の同僚とISUCONというコンテストに出ることになり、7月くらいから同僚と集まって練習をしたりもした。 チーム外の人と集まって何かをやること自体も楽しかったし、ここを通じて得られたものも多く、結果は出せなかったがとても良い経験だったと思う。
仕事以外
生活面では3月に結婚式があったり、6月にはお休みをいただいて新婚旅行に行ったりで、その間にはダンスのイベントに出させてもらったりと上半期はとにかくイベント盛りだくさんで慌ただしかったが、 とても充実して楽しい時間を過ごさせてもらえたように思う。
結婚式に関しては、転職して間もないこともあり現職の人をほとんど誘えなかったことや、どなたに祝辞をお願いするかなどタイミングの問題などもあり非常にアタマを悩ませた。 ただ結果として、色々な方々のご協力、支援のおかげもあり、自分たちの希望に沿う形で対応していただくことが出来、おかげさまで思い出深い素敵な1日を過ごす事ができた。 助けたいただいた方々には本当に頭が上がらない思いです。
あと2月頃には目黒雅叙園で前撮りをした。式が洋装なこともあり、和装ですてきな庭園があるこちらでは、場所はもちろんスタッフの方々も素晴らしく素敵な写真をたくさん取っていただいた。 すでに人気のスポットだが、あらためてここはすごくオススメしたいスポットだった。
今後
まずは仕事面でもっとバリューを出していけるようにしたい。 そのためにはエンジニアとしての技術力はもちろん、調整ごとやファシリテート力に難がある今の状態をもっと改善していく必要があると感じる。 前職での最後の方から、課題感は感じつつも出口が見えなかった状態から少しずつ進むべき方向が見えてきたような状況までにはなれたように感じているので、 少しでも先に進みつつ早い段階でここをうまくコントロール出来るようにしたい。
また、仕事面、プライベート面ともに新しいことをやるという経験が少なくなっているので、今月から1つずつでも「何か挑戦すること」と、今年もとわずかなので、今年の間「継続して取り組んでいくこと」というのを掲げて、 実践を試みているので、あと2ヶ月強走りきりつつ、少しでも手応え・成果を感じられるように過ごしたい。 とりあえず新しい挑戦として、今月は初心者向けのフットサルイベントに参加して、初めての経験と盛大な筋肉痛を得てきたが、とても楽しかったので今後も自分のペースで参加したいと思う。 来月と年末に何するかまだ決められていないので、まずはそこをかんがえて見るところから
また「継続して取り組んでいくこと」については、このブログなどでアウトプットとして成果を出せればとは思いつつも、インプットばかりでうまく進められていないので、まずは重い腰を上げてみるところから頑張ってみようと思う。
おわり
転職して1年が経過したので振り返り
昨年の10/15に約10年間働いた前職を退職し、10/16より現職に転職した。 人生で初の転職を経て1年間経ったので振り返ってみる。 思ったより長くなりそうなのでまずはpart1。2018年の振り返りから
前職と現職について
前職も現職もwebサービスのエンジニアということで同様の職種での転職になる。 担当サービスは、前職ではメール・FAXといった低レイヤーなところから、法人予約サービス、口コミシステムや航空券予約システムなど色々担当したが、 基本的にはオンライン旅行予約システムの開発だった。 現職では動画配信サービスの契約、決済周りなどを担当することになり、今まで未経験の新しい部分を担当させてもらうことになった。
また、規模も前職では約200人弱で国籍も様々なところから、約80人くらいでチームメンバーは全員、日本人と大きく環境が変わった。
2018/10〜12月
仕事面
最初の1ヶ月は今まで色々と環境が違いすぎてとりあえず戸惑いながら1年を過ごした記憶 メンバーや関係者、タスクの進め方、会議や決め事などの進行の仕方など、あらゆることが新しい環境で変わったので、 もちろん変化の大小はあるけれども、社内のツールの使い方や担当サービスのことなど分からないことだらけだった。 幸いにもチームのメンバーが親切に色々教えてくれたので、そこから少しずつ情報をキャッチアップできたのは良かった。
1箇所にどうしても10年近くとどまっていて、かつ他の環境を知らないと、「今までの常識=世間での常識」みたいに思い込んでしまっていたところも多く、 そこでの戸惑いや最初になるべく早くバリューを出そうという焦りなどから、年内はいろいろと迷惑かけてしまったり、ちょっと変な方向に暴走してしまったことも少なくなかったように思い、ここは今でも反省しているポイントの一つ。
組織・環境について
出来ればチームのメンバー全員やその他の人何人かとランチに行きたいと思いつつ、チーム内の数人しか出来なかったのは、未だに残念でならない。 ただ、週1で10人弱くらいでやっている技術ランチにうまく潜り込めたおかげで、顔はわかるという人も増えたり、普段、業務で関わらない人と話をする機会を得られたのは良かったし、それが今にも続いているのはありがたいことだったので、ここは良かったポイントだと思っている。
前職に比べて仕事の面では、手続きやフローと言ったものがほとんどなく、組織も基本フラットなため、自分の業務に集中できる時間が増えた。 また、今までは運用などに取られる時間がかなり多かったが、そういったこともリセットされて今までにないくらい開発に集中させてもらえる部分については転職してよかったなと思えた。
仕事以外
生活面など仕事以外の部分では、11月に入籍をして、入籍前からちょっとだけ進めていた結婚式についてちゃんと考えることに。 結果としては、翌年の3月に式を行うことになったので、早速打ち合わせやら何やらの準備を始めることになった。 この時点では、それほどやることが多いわけではないが、初めて知ることがいっぱいあって情報量が多く、そこが消化しきれず結構バタついていた気がする。
その他にも家の方の用事があったり、結婚式の準備としてダンスのレッスンに2人で通うようにしたりで、休日はだいたい何かしらの用事が入っている、という状態だったかと思う。 あと、式にどれくらい、どんな人を呼ぶか?2次会とかはどうするか?あたりで結構、話した気がする。
年末
年末に向けて、以前からあるサービスの担当にちょっと関わらせてもらう機会をもらうことになり、 いわゆるレガシーシステムをドメインナレッジなどから学んで、簡単な対応をしていくという機会もあり年末の仕事としてはそれでバタバタしていた。 ただ、今までさんざんレガシーシステムを経験してきた経験は少しばかり活かせたように思う一方、開発環境などでも思った以上にインフラ部分をサーバサイドエンジニアが触れなくてそのへんにはかなり戸惑ったし、そのあたりでもっと貢献したいと思っていただけに、そこについては残念だった。
そんなこんなで最初の3ヶ月を過ごしたが、 * ひたすら知識を入れつつ環境に少しでも早く慣れることが出来るように頑張った * 開発、特にコーディングに集中し今までとは良い意味で違う進め方が出来るようになってきた というのがこの間の所感でした
つづく
Architecture Night #2に参加してきた
Architecture Night #2
2019/10/18@サイバーエージェント
https://architecture-night.connpass.com/event/147171/
10/18(金)に「アーキテクチャナイト」というアーキテクチャについての各社の取り込みや思想についての発表があるイベントに参加してきました。 ここ最近は言語やツール、もしくはサービス・会社単位での勉強会のみならず、こういった設計やアーキテクチャをテーマとした勉強会が増えているように感じます。
1.WinTicket におけるリアルタイム性と高負荷を考慮したアーキテクチャ(CyberAgent 江頭さん)
メモ
- WinTicketとはオンラインの競輪投票サービス
- 購入・払い戻しのすべての責任を負う
- 常に最新の情報を取得・提供する必要がある = リアルタイム性が求められる
技術スタック
- golang
- k8s(GKE)
- envoy
- アンバサダーパターンを利用
- 当時はistioはアルファやベータ版が主だったのでenvoyを選択
- cloud spanner(DB)
- 3secでスケールアウトできる
fastly
映像周りは aws(elemental media service)
- 認証はfirebase
k8s
- 36個のマイクロサービスが動いている
- Gatewayパターン
- アンバサダーパターン
- どこかが落ちても継続して動かし続けたかったため
- オートスケールが出来るような構成
envoy
- サービスメッシュで可用性の向上
- Outlier detection
- 異常検知のこと
- ここではエラーが多い場合に自動で外す機能のことっぽい
- circuit breaker
- LB
- retry
- ロールアウト時に500エラーを返すなどが結構あるので、その場合にもenvoyがリトライやアクセスが行かないようにするなどハンドリングしてくれる
- Outlier detection
- ロギングなども envoy任せにしている
cloud spanner
- 下記の要件、リスクに対応できるようなものとしてcloud spannerを利用
- 金銭の取引があるのでトランザクション必須なため
- 購入できない場合は事業的損失が大きいというリスク
- レースの締め切り直前などは負荷が大きいというリスク
fastly
- リアルタイム性が求められるので利用
- Instant Purgeが決め手だった
- 導入した結果レイテンシをかなり抑えられている
- goのsingleflight という関数の多重呼び出しを抑制するメカに済でキャッシュミス時のオリジンへの負荷対策をしている
- キーに対して1つしか実行されない
- 参考. golang.org/x/sync/singleflightで重複呼び出しを排除する
サービス
- 払い戻しはキューイングしてワーカーで処理(cloud pub-sub)
- 30 万ユーザーに3分以内に払い戻し、という要件に対応するため
- 1000 ユーザー/sec で払い戻しできることを確認
- 当初の要件は満たせていないが、3 分で18万ユーザーなのでとりあえずここに着地
- 払い戻しはロックを取っている
- ロックでぶつかることはあまりない。ぶつかっても問題にはなっていない
- ミッションクリティカルな処理では UUIDv4 をリクエストに付加して多重実行を防いでいる
- ユーザ作成などは requests テーブルを用意して多重実行されても重複エラーになるようにしている
分散システムでのデザインパターン(?)
感想
お金が絡んでいることやリアルタイム性が重視されていることからか、要件もかなり高度なものが求められているように感じたが、 そこに対してGKEの機能やサービスをうまく活用して対応しているという印象を受けました。 分散システム、クラウドサービスをりゆおする場合のデザインパターンやWebの仕組みを踏まえた対応を、 サービスの環境を活用しながら着実にそして確実に実践することで、おそらく規模の大きいサービスをしっかり運用されているのだなと思い、 学ぶべきところ、見習うべきところがたくさんあるのではと感じたセッションでした。
2.秒間数千万メトリクスを裁く監視基盤のアーキテクチャ(LINE 株式会社 @dxhuy さん)
メモ
Observability
- 昔から使っているモニタリングプラットフォームを使っている
メトリクスのストレージを自前で開発している
- put(バッチ insert)とレンジを指定してデータポイントをクエリする 2 つの機能のみ
mysql や OpenTSDB では限界がきたので新しいストレージの開発の着手を始めた
- OpenTSDB でも書き込みは早いが、read に時間がかかる
- その他の OSS も試したが要件を満たせるものがなかった
要件
- 1ホスト辺り1万弱のメトリクスを保存。それを数十万ホスト
アーキテクチャ
- 機能ごとにマイクロサービスに分散
- 直近 28 時間のデータを全部メモリにのせる
grpc を利用 -> 早くはない。便利な機能が揃っている(クライアント LB など)
Redis や Memcached などは時系列データを効率的に圧縮するのが難しいため利用できない
圧縮には Facebook goriila delta-delta XOR アルゴリズムを利用(prometheus と同様)
再起動対応は、Write Ahead log(ディスクに書いてからメモリに保存)。ディスク保存のバックエンドは RocksDB
ネットワーク障害などによるロスを防ぐために、書き込み失敗した場合は kafka に書き込んで、DB に流している
1つのホストが死んでもデータロスを発生させない
- RAFT ベースでクラスターを構築
永続ストレージは cassandra を利用
- in-memory から GRPC で cassandra に転送
- 4h ごとにバッチ転送
表側は grafana だろうが prometheus だろうが http/udp などだいたい対応している
スケールイン/アウトによるリシャーディングは?
感想
LINEさんのような大規模なサービスでの社内プラットフォームに求められるレベルの高さとともに、 その高いレベルの要求に対して、理論や今まの経験に基づくナレッジやスキル、その仮説や仕組みに対しての検証などをフルに活用されて対応しているということを、 良い意味でまざまざと見せつけられたセッションでした。 理論やアルゴリズムやデータに関することなど、初めて聞く内容も多いセッションでしたが、すごく丁寧に、なぜ?どうして?を説明されていてとても興味深いセッションでした。
3.MirrativサーバのCleanArchitecture移行物語(株式会社ミラティブ 夏さん)
メモ
- Android/iOSはflux化を進めている
- webではCleanArchitecture を導入
- API仕様はblueprintを利用
- goでclean architcture
- まずは慣れている perl を元に Clean architecture での設計をして go に移植していく予定
方針
感想
レガシーシステムにどう対応していっているのかについてのセッションで、 自分もここまでアーキテクチャなどをしっかり考えた対応ではないものの、レガシーシステムの作り変えなどの経験があったので、 その経験などを振り返り、共感したところやなるほど、そうやっているのかと思うところなどがたくさんあり、思わずメモもあまり取れずでした・・ 自分たちの手に馴染んでいる言語で、まずどう作っていくかや検証などを進めつつ、新しい言語、アーキテクチャに段階的に移行していくという手法は、 こういったケースで非常に有効なのではと思い、今回、学びを得たポイントの一つでした。
懇親会
懇親会では、iOSエンジニアの方やSREとサーバサイドエンジニアを兼務さrている方などとお話をさせていただいたが、 みなアンテナが高く、守備範囲も広く、自分も、もっと経験や興味の幅を広げるなどをしてその辺りをキャッチアップできるようにならなくてはと感じました。
あと印象的だったのはサーバサイドはなるべく状態を持たないようにして、アーキテクチャと状態は疎にしていく、というのがベストプラクティスだと言われることが多い一方で、 フロントエンドやiOS/Andoroidアプリは状態を管理するためのフレームワークが需実していたり、そこをどう管理してくのかについての議論も多く、「状態」をうまく管理してくことが求められるので、その辺りに違いを感じるという話がありました。 言われて確かにと思った一方で、自分がメインとしている分野以外もキャッチアップしていくことで「見えてくるものや得られるもの」の重要さを感じた一幕でした。
総じて、得られたものが多く、参加できてよかったイベントでした。主催、運営の方々どうもありがとうございました!
isucon2019予選 1日目の参加記録
イントロダクション
9/17(土)にisuconに会社の同僚2名(以下 Aさん、Bさんで表記)と参戦してきました。 結果は、あえなく失敗でしたが、集まってわいわい言いながら問題に向かっていく、というのはとても楽しかったです。
また、問題も今までとは傾向の違うところがあったり、なるほどーと思わされるところがあったりと、とても楽しませていただきました。 運営の皆様、そして一緒に出場してくれた同僚の2名、どうもありがとうございました!
isucon9予選の問題
isucariという椅子を売りたい人と買いたい人をつなぐサービス UIや画像からマイクロサービスでのサーバーサイドのアプリケーションまで、すごくしっかり作り込まれていました。
同僚と振り返りで出た話でも、今までの問題と比べて改善ポイントが見つけづらかった、というのが出ていました
当日の記録メモ
AM10:00〜
会社の会議室に集合して準備。公式で10分ほど遅れるとのアナウンスがあり、おっとトラブルかー、という気持ちと、「10分で直すってすごいな。。大丈夫かな」とか考えていましたが、 本当に10分もかからず対応完了で10:10から競技開始。
早速マニュアルの確認から。 isucari...、あ、本当にメルカリで来たのか。 け、決済、、QR、、ここまで、対応しているのかと思いながら、マニュアルを眺めていました。
その間に、AさんがAlibabaCloudでインスタンスの作成。 自分はAWSとかもちゃんと触ったことなかったので、ふむふむと見させてもらいつつ自分一人だったら絶対ハマってたなぁと思ったりしていた。
無事にインスタンスが作成されてIPが共有されたので各自sshの設定をしてログイン。 その後、サーバのプロセスや確認してnginx,mysqlが動いていて初期実装でgoのアプリが動いていることを確認。
自分はそれと並行して、運用スクリプトをいじったりansibleの設定を直したりしていた。
Bさんはgoの設定やリポジトリへのpushをしたり、schemaSpyというツールでスキーマ構成を把握したり、アプリのコードを追いかけたりとしてもらっていた。 これのおかげでローカルでのコンパイルやインスタンスへのデプロイも手軽に出来て効率的に進められたように思う。
AM11:00くらい?
ここらで、まずはベンチを動かしてみることに。 nginxのログ設定とmysqlのスロークエリログの設定をしてベンチを開始、だが、スロークエリが出ない。。 設定を確認してみたらスロークエリOFF、ロングクエリタイム=1になっていた(逆にしたつもりでいた)という感じで、初っ端からミス・・
気を取り直して、設定を修正して再度ベンチを実施。 インデックスちょっと張ってみるかーといった話が出てきたり、ログやコードからN+1クエリ直さないとね、という話をしたり、 categoriesあたりはメモリに載せちゃおうかという話をしたりしていた。
ここで分担しつつ作業を進めていくが、ローカルでアプリがうまく動かせず、それと並行しつつ対応。 とりあえずローカルでコンパイルして問題なければ、サーバにデプロイして確認するかーという感じなり、それぞれの担当作業に着手。
Bさんがものすごい勢いでN+1クエリを解消。あとでコミットログ見ると凄まじい発想力と実装力。。まじで神・・ 自分はcategoriesのキャッシュ化に着手。 Aさんはクエリのインデックス作成や問題のありそうなクエリや実装の調査を対応。
go力や把握力が低くて、まずなぜかMapでのキャッシュ化を試みて、時間をかけて対応したものの、全然使えないことに気づく。。マジで使えないやつ。。 その後に、構造体でちゃんと持てばいいじゃんと気づき、対応するものの、既存のクエリでは全件、取得のところしか切り替えられず、 他のところはフィルタリングなどがうまくいかずつまる・・
そんなこんなしているうちに、BさんがN+1を解消した実装でベンチを回すが、あれ、、あんまり負荷が上がっていかない?という話が出てきた。 Aさんがマニュアルをチェックしてくれて、ここでキャンペーンの設定があることに気づく。
ここの変更と自分の中途半端な実装を混ぜて一旦デプロイして再度、ベンチを回してみることに。 まずはレベル4で、当然のように落ちる。。
スロークエリを見てみてもあまりそれらしいものは出てこないのでDB問題ではなさそう。 nginxのログから新着一覧の取得あたりが遅そう?という話になり、とりあえずそのあたりも含めてがっつりコードを追ってみることに。 自分はAPIのコードや呼び出し部分もしかして改善必要?と思って見てみたり、/buyが怪しそうということで、処理の流れを見ていたりした。
PM0:00~2:00くらい
確かこの辺りで、カテゴリのparent_id引いているところ決めてうちで固定値で何とかなりそうでは、という話がAさんから出て対応してもらったり、改善できそうなクエリを直してもらったりした。 途中、/buyのuserのロックいらないのでは?と思い、FOR UPDATE外してみたり、不要なロックしている箇所がなさそうか見ていじってみたりしたが改善が見られず・・ 思い返してみると、この辺でnetdataやプロファイルとか入れられればよかったかも。
途中nginxが1コアしかつかっていない事に気づいて設定を修正してもみるが、改善は見られず。
PM2:00くらい
いったん昼飯を挟みつつ、goのnet/httpが同一の最大接続数のデフォルト設定が2であることを発見。 32まで増やしてみるが変わらず・・いま思えばもっと前で止まっているので当然・・
お昼食べつつ、みんなでマニュアルを見返して、あー、ちゃんと更新や登録は即座に反映しないとって明記されているね。って話をしたり、 カテゴリ新着一覧はやたら「即座に」って書いているのに、新着一覧がないのは即座に返さなくていいってこと?インデックスページなのでキャッシュ使って改善した方がいいのでは?どうしようかー という話が出て、主眼は新着一覧ページをどう改善するかに変わってきた
PM3:00くらい
ここでAさんが高い商品を買ってもらえるようにすればスコア出るのでは?クエリのORDER変えてみては?という話から、それやってみようとなり、対応してもらうものの、どうやらここはいじってていけない的なエラーが発生。 この辺り、AさんとBさんのお二人が色々トライ&エラーで対応してくれていて、自分はAPI呼び出し部分なんとか出来ないかなー、もしくはロック減らせないか、とか考えいていたが何も出てこず。。
pprofでプロファイル取ってみたのは、この辺だったはず。 やっぱり新着一覧がって話とログイン周り時間かかっているねって話になり、ログイン周り見てみるが怪しげなところが見つけられず。 プロファイルでログイン周りのロジックで負荷が高そうというのは出ていたものの、ハッシュ化のところで、ん?ってなったが、ここはいじれないかーと思い、手を出さなかったのは、後悔ポイントの一つ。せめてcostいじっておくべきだったよ・・
この辺でnetdataも入れてみる。ポートが開いておらず試行錯誤。AlibabaCloudのコンソールでポートを開けてもらいやっと見れる状態に。 この辺でハマる自分のレベルの低さを痛感。。
トライ&エラーでログをみながら、ロックってログが出てるなんだろ?/buyだね、という話になり、同僚がロックエラーが出ているIDをログに出してみようと提案。 早速、対応してもらいベンチ回してみると同じ商品に対する購入処理が集中して、落ちていることが判明。 神エンジニアが排他制御を入れてくれ、ベンチを回してみると、5,000くらい?(記憶が怪しい)がスコアが出てくれるようになり、光が見えてきた。 その後、数回、ベンチを回してみてちゃんとスコアが出るようになったことを確認しつつ、同僚二人が諸々、修正を実施してくれて5,000くらい?で一時的に30位以内(たしか、そのくらい)に入った。
PM4:00
CPUがボトルネックであることはわかっていたので、よし、これを複数台構成にすれば、もっと改善するのでは?ということで、この辺りか複数台構成への変更に着手開始。 排他制御はこのままだと複数台構成にできないということで、redisを使って排他制御をする事に。これを同僚がサクッと実装、マジで神。
redis自体は自分が用意していたansibleで入れるつもりがエラー連発。 結局、同僚が見つけてくれた対応方法を実施したり、同僚が対応入れてくれたりで解決。
ここから自分はnginxの複数台構成の設定に着手。
PM5:00
間違えてグローバルIPで接続しようとしたりするなどショボいミスをしつつもとりあえず設定完了して、ベンチ開始。 ちゃんと振り分けができていることは確認できたが、どうにもすぐ落ちる。 ここで、画像が複数台対応してないじゃん、と気づき/uploadの場合、自サーバのみを見るように変更。 しかし、それでもまだ落ちるし、IPエラーみたいなログも出るし、時間もないしで調査。 ここで、/sellも画像、関係していると気づき対応しtベンチを回す。これが確かPM6:00前くらい。
ギリギリで間に合ったかと思ったがFAILし、結局、このまま解決せずタイムアップ。
タイムアップ後
ログを確認していると、なぜかhttp301が出ている事に気づく、これに気づきnginxのlocation設定が間違っている可能性が浮上。 手元の環境で設定を直して、画面から確認してみるとエラーになるところが解消。"/sell"とすべきところを"/sell/"にしていたせいという、痛恨のミス。 これは本当に申し訳ないことをしてしまった・・ マジでちゃんとnginx勉強しとけよ自分、と切に、切に思いました。
p.s 帰宅後、同僚が入れてくれた修正などを見て、あの短時間でここまでの修正を、、これをFAILにしてしまって本当に申し訳ない気持ちでいっぱいになりました
全体振り返りなど
- ansibleやログローテスクリプトなどを事前に用意していたが、色々ツメが甘くログローテスクリプト以外はあんまり役に立たなかった気がする
- ansibleはubuntuでの設定ファイルの構成に合わせておくべきだった(isucon8のcentosの構成に合わせていたため勉強不足もありハマった)
- goでのロジックがさらっと書けなかったのは、単純に力不足と練習不足だったのでここはちゃんと勉強しておく
- newrelicなどマイクロサービスでのボトルネックなどを可視化出来るようなツールにも慣れておく
- nginxとmysqlは基本なので定期的に勉強しておく
来年も機会があれば参加したいです。なので、それまでの今回の反省点を少しでもつぶせるようにしたい