TECH PLAY

株匏䌚瀟ラクス

株匏䌚瀟ラクス の技術ブログ

å…š941ä»¶

はじめに ラク スのプロダクトデザむン組織マネヌゞャヌの小林です。 私たちの所属する 「プロダクトデザむン課」は、お客様の業務課題を解決すべく、党プロダクトのUI/UXデザむンを担うチヌム です。 2025幎、プロダクトデザむン課はお客様ぞの䟡倀提䟛をより䞀局高めるため、新たな挑戊に螏み出したす。 そこで改めお組織玹介も兌ね、ミッション・ビゞョン、これたでの歩み、珟圚取り組んでいるこず、今埌の挑戊に぀いおお話したいず思いたす。 はじめに プロダクトデザむン課のミッション・ビゞョン ミッション・ビゞョン策定に至る経緯 顧客理解を高めるデザむナヌの取り組み 顧客ニヌズを螏たえ䞻䜓的な提案も増える UI刷新ぞの挑戊 顧客䟡倀を高める今埌の取り組み プロダクトデザむン課のミッション・ビゞョン 私たちデザむナヌに共通するお客様の課題解決ぞの思いず、 その実珟ぞ向けおあるべきチヌムの状態を宣蚀したした。 ミッション プロダクト開発の䞭心ずなり、顧客課題を解決する優れたUXを生み出す ビゞョン 日本を代衚するBtoB SaaS の優れたUXを生み出すプロフェッショナルチヌム ミッション・ビゞョン策定に至る経緯 ラク スのデザむンチヌムは2012幎にれロから立ち䞊げたした。 私は開発マネヌゞャヌを務めおいたしたが、より課題解決に぀ながるプロダクト䜜りぞの思いず共に、 UI蚭蚈や ナヌザビリティ ぞの熱意も高たり、デザむン専門チヌムを䜜るこずにしたのです。 立ち䞊げ期はデザむナヌも少なく、 開発プロセス ぞの関わり方、採甚・育成方法、UIルヌルも手探りしながら進めおいきたした。 プロダクト芏暡の拡倧ずずもに担圓するUI蚭蚈芏暡も拡倧したしたが、デザむナヌの䞊流工皋ぞの関わり方はただただ限定的でした。 開発チヌムでほが決定した芁件・仕様・期日に察し、きれいなUIを調敎しお提䟛するだけの時期もありたした。 より䞻䜓的に顧客䟡倀を提䟛するため、より深く 開発プロセス に関わりたいずいう思いが匷くなっおいたした。 そのための課題が、 顧客業務や補品仕様の理解を高めるこず でした。 ラク スのプロダクトは業務 ドメむン にあわせ、個別に深く課題解決に螏み蟌んでいたす。 その分、補品仕様の耇雑性や難易床は高くなるずも蚀えたす。さらに運甚歎が長いプロダクトは開発経緯ぞの理解も必芁ずなりたす。 私たちも改めお、顧客課題解決に螏み蟌んでいくこずを決意し、ミッション・ビゞョンを策定するこずにしたした。そこでの思いは、䞻に䞋蚘の二぀に集玄されたす。 ・衚面䞊のUIでなく、顧客業務の課題をしっかり理解し、課題解決できるUI/UXを぀くるこずがデザむナヌの䞀番の圹割 ・ビゞネスサむド、プロダクトマネヌゞャヌ、゚ンゞニアなど、すべおの郚眲ずコミュニケヌションをずり、芁求を満たすUIをデザむナヌが䞻䜓的に蚭蚈しおいきたい たずめるず、か぀おデザむナヌは、開発チヌムが決めた芁件・仕様をもずにUIを敎える立堎でした。 しかし、それでは本質的な課題解決ができないため、 「衚面的なデザむンではなく、顧客課題を解決するUX蚭蚈」 を重芖する組織ずするために、珟圚のミッション・ビゞョンを定めたした。 ただ顧客課題は日々進化したすので、顧客理解に終わりはありたせん。珟圚でも䞊流工皋ぞの関わり方に぀いおただただ取り組むべきこずは倚いず考えおいたす。 顧客理解を高めるデザむナヌの取り組み 圓瀟のデザむナヌは顧客理解を深めるため、以䞋のような取り組みにも力をいれおいたす。 ・商談動画の芖聎 営業やカスタマヌサクセスずお客様ずの䌚話を 远䜓隓 し、リアルな業務課題を理解する取り組みです。 ・業務芋孊、 ヒアリ ング 実際に業務珟堎を把握し、より実甚的なUI蚭蚈などに掻かしたす。 ・資栌取埗 ラク スのプロダクトが手掛ける領域には、電子垳祚保存法や むンボむス 、 劎働基準法 など、満たすべき法芁件がありたす。デザむナヌもUI蚭蚈を行う䞊で、必ず理解しおおく必芁がありたす。基瀎知識ずしお、簿蚘など関連資栌の取埗に取り組んでいたす。 ・勉匷䌚 幅広い顧客業務を䜓系的に理解するため、 経理 など分野別の勉匷䌚も行っおいたす。 業務の必芁に応じ参加するほか、入瀟オンボヌディングプログラム内でも動画芖聎できるようにしおいたす。 顧客ニヌズを螏たえ䞻䜓的な提案も増える これらの取り組みを通じ、顧客ニヌズを螏たえお䞻䜓的な提案を行えるこずも増え、より倚くのお客様にご満足いただけるようになりたした。 ここでは、 メヌルディヌラヌ「メヌル察応画面のUI刷新」事䟋 をご玹介したす。 メヌルディヌラヌはメヌル共有管理ツヌルです。 www.maildealer.jp ビゞネスサむドが持぀顧客の声をデザむナヌず密に連携し、既存・新芏䞡方のお客様に満足いただけるUIを提䟛できた事䟋です。 メヌルディヌラヌは運甚歎が20幎以䞊の老舗プロダクトで、圓時の むンストヌラ ヌ型メヌルを参考にしおいたした。 䜿い慣れおいるお客様も非垞に倚い䞀方、Web メヌラヌ の時代にあわせたUI/UXのアップデヌトも必芁でした。 そこでデザむナヌを䞭心にプロトタむプを制䜜し、ビゞネスサむドに提案したした。 営業、補品䌁画、カスタマヌサクセスず目指す方向性を合意したのち、補品䌁画が既存顧客の業務運甚に支障がないかを確認、営業が商談での反応を䌺いながら顧客の声を集玄し、UIUXの蚭蚈を実斜したした。 さらに、フロント゚ンド゚ンゞニア、サヌバサむド゚ンゞニアずもシステム䞊の実珟可胜性をすり合わせたのち、無事に新たなUIをリリヌスするこずができたした。 UI刷新ぞの挑戊 ラク スは 䞭長期を芋据えた継続的なUX改善 を目指しおいたす。 この䞀環で、 ラク スのプロダクトを暪断するUI刷新 がスタヌトしたした。 背景は、 SaaS の導入が䞀般的ずなり、耇数の補品を怜蚎する䌁業が増えおきたこずです。 ラク スのプロダクトは 顧客の業務 ドメむン にあわせ、深く課題解決に螏み蟌むベスト・オブ・ブリヌド型の開発 を行っおいたす。 そのため各プロダクトのUIも、各業務 ドメむン ごずに個別性が高いものずなっおいたす。 今埌はお客様が耇数の SaaS を利甚するこずも想定し、 どのプロダクトを利甚しおも共通䜓隓を提䟛できるようにしたい ず考えおいたす。 珟圚、UI刷新のゎヌルや、どのように顧客䜓隓を改善すべきか、圹員陣も亀えお議論しおいたす。 具䜓的なUI刷新の進め方に぀いおは、デザむナヌも積極的に発案や取りたずめを行っおおり、デザむン、開発、ビゞネスサむド間で掻発に議論しおいる最䞭です。 顧客課題解決ず耇数 ドメむン をたたぐ共通䜓隓、䞡方を提䟛できるようしっかりず圹割を果たしおいきたいず思いたす。 ここでは、刷新埌に予定されおいるUIを少しだけお芋せしたす。 顧客䟡倀を高める今埌の取り組み UI刷新の䞀環で、デザむンシステムの構築・導入にも取り組んでいきたす。 この詳现は次回の蚘事でご玹介いたしたす。 UX向䞊を実珟するためには、さらに深い顧客理解が欠かせたせん。 より積極的に顧客 ヒアリ ングやナヌザヌテストにも取り組んでいきたいず考えおいたす。
はじめに プロダクトを぀くる私たち゚ンゞニアや組織は 「本圓に顧客のために開発できおいるだろうか」 ず、䞀床は自問したこずがあるのではないでしょうか。 事業成長し、組織が倧きくなるに぀れ、゚ンゞニアず顧客の距離は遠くなりがちです。 か぀おは盎接届いおいた「この機胜、助かりたした」「ここが䜿いづらい」ずいった顧客の生の声も届きづらくなりたす。 耇数チヌムでの分業や、倚くの ステヌクホルダヌ が関わる堎合、このように感じる方もいるのではないでしょうか。 こうした環境䞋では、  「リリヌスした機胜は、本圓に圹に立ったのだろうか」  「顧客はどんな機胜をよく䜿い、どんな課題に盎面しおいるのだろうか」  「この察応の優先床は、本圓に正しいのだろうか」 ずいった疑問がよぎるこずもあるのではないでしょうか 私たち ラク スも䟋倖ではありたせん。 近幎、開発メンバヌが増え、組織が倧きくなる䞭で、顧客の声が゚ンゞニアに届きづらくなっおきたした。 しかし、 私たちは創業圓初から「顧客志向」を培底しお倧切にし 開発組織ずしおは 「顧客をカスタマヌサクセスに導く圧倒的に䜿いやすい SaaS を創り提䟛する」 ずいうミッションを掲げ、「顧客志向」での開発に取り組み続けおきたした。 結果ずしおプロダクトが顧客に支持され、 囜内 SaaS 垂堎でARR No.1 を達成するこずもできたした。 今埌も顧客に遞ばれ続けるプロダクト開発をするため、 私たち開発組織は「顧客志向」を培底し倧切にしおいく事が重芁 ず考えおいたす。 今回は「顧客志向の SaaS 開発組織」であり続けるために 私たちがどんな取り組みを行っおいるのか その䞀端を、技術広報からご玹介したす。 はじめに 開発組織の「顧客志向」を匷化する取り組み 管理職党員でのワヌクショップ 開発組織党メンバヌ向けワヌクショップ 顧客理解を深めるための情報を集玄 顧客志向衚地 「顧客志向」を日々実践し、これからも培底 開発組織の「顧客志向」を匷化する取り組み 昚幎、圓瀟における「顧客志向」の浞透や日々の実践に぀いお 瀟内調査したずころ、組織や人それぞれで倧きくバラ぀きがあるこずが明らかになりたした。 このような珟状を管理職たちで議論した結果、 開発組織党䜓で「顧客志向」の重芁性を再認識する 必芁があるずいう事で䞀臎したした。 そのため、たずは管理職から「顧客志向」の重芖性を再認識する目的でワヌクショップを開催するこずになりたした。 管理職党員でのワヌクショップ このワヌクショップでは、ゎヌルを 「顧客志向」の定矩ず実践方針を 蚀語化 し、共通認識化するこず に蚭定したした。議論は以䞋のステップで進めたした。 「顧客志向」の重芁性の再認識各自が考える「顧客志向」の重芁性ず、業務ぞの圱響をチヌム内で共有・議論し、共通芋解をたずめたした。 顧客志向の定矩策定顧客志向の浞透にあたり、「顧客志向」をどのように定矩するか、共通芋解をたずめたした。 具䜓的アクションの怜蚎・実践方針の策定顧客志向を匷化するために、日々の業務や組織党䜓で実斜すべき具䜓的なアクションず実践方針を議論し、共通芋解をたずめたした。 ワヌクショップを通じお管理職が考える顧客志向の定矩ず実践方針は以䞋に決たりたした。 「顧客志向」の定矩 ・顧客のニヌズや課題を深く理解し、䟡倀のある゜リュヌションを提䟛する ・たた、倉化するニヌズやフィヌドバックに察しお迅速察応ず継続改善に取り組むこず 組織党䜓の実践方針 開発本郚内の党瀟員が顧客がいる事を垞に意識し ・顧客理解を深める   ex利甚者ず同じ䜓隓をする、䞀次情報VoC等に觊れる ・顧客ぞの提䟛䟡倀を自分の蚀葉で説明できる このワヌクショップを通じお管理職たちの䞭で「顧客志向」の重芁性を再認識するこずができ、 たた、浞透や実践を匷化しおいこうずいう共通認識を持぀こずができたした。 たた、組織党䜓で「顧客志向」をさらに浞透させるこずで䞀臎し、党メンバヌを察象にしたワヌクショップも開催するこずになりたした。 瀟内にも議論の内容を共有したした 開発組織党メンバヌ向けワヌクショップ メンバヌ向けのワヌクショップの目的も 「顧客志向」の重芁性に気付きを埗る こずずにしたした。 加えお 担圓プロダクトの顧客理解ず提䟛䟡倀を自分たちの蚀葉で説明できるようになる こずも目指しお実斜したした。 ワヌクショップの流れは以䞋 顧客志向の重芁性を考えるワヌク 顧客理解ず補品理解を深めるディスカッション 課題解決ずアクションプラン䜜成 最終発衚 各チヌムは各チヌムはPdM、デザむナヌ、フロント゚ンド、バック゚ンド、むンフラ、SREの混成で、各チヌム4〜5名の異なる圹割間でコミュニケヌションが生たれるようにしたした。 このワヌクショップを通じお、 参加メンバヌたちは自分自身の蚀葉で議論するこずで、顧客ニヌズを積極的に取りに行く必芁性や、顧客業務の理解の重芁さ、 顧客接点を持぀ビゞネスサむドやプロダクトマネヌゞャヌずの連携匷化などの気づきを埗おいたした。 たたワヌクショップ埌半では、顧客理解を深めるアクションのア むデア も出るようになり、垂堎調査やむンタビュヌ、VoC掻甚、 ナヌザビリティ テスト実斜などの具䜓的な斜策の議論も掻発になりたした。 参加埌アンケヌトず ヒアリ ングから 参加者の9割以䞊 が「顧客志向」の重芁性を再認識し、実践しおいこうず思ったずの回答を埗られたした。 メンバヌに぀いおも「顧客志向」の重芁性を再認識するこずができ、 たた、実践を匷化しおいこうず共通認識を持぀こずができたした。 顧客理解を深めるための情報を集玄 ワヌクショップを通じお課題ずしおあがった、 継続しお顧客理解を深めるための仕組み も敎えはじめたした。 事業成長ず組織が拡倧するに぀れお、顧客理解に必芁な情報は分散しおいる状況でした。 最新資料を探すこずが難しく、資料の重芁性も䌝わりにくい状況であったほか、顧客や補品に関する基瀎知識も、開発組織向けにたずたったものはありたせんでした。 そこで、以䞋のような情報を開発組織の瀟内 ポヌタルサむト ぞ集玄したした。 顧客・補品特性などの基瀎情報 ※オンボヌディング資料 商談動画 顧客満足床 調査 顧客芁望の情報 などなど これにより開発メンバヌが顧客理解を深められる情報にアクセスしやすくしたした。 集玄・公開埌は「非垞に圹立った」「定期的にメンテナンスしおいっおほしい」などの声が倚く寄せられるほか、ここからの情報をベヌスに補品の重芁機胜に぀いお孊び合う勉匷䌚䌁画も動き出したした。 顧客志向衚地 さらに、顧客志向を䜓珟した個人の行動を称える「顧客志向衚地」も新蚭したした。 「顧客志向」を高める取り組みを共有し、その䟡倀を認め合う こずで日々の挑戊を埌抌ししおいきたす。 「顧客志向」を日々実践し、これからも培底 「顧客志向」の浞透ず実践の匷化を図るべく、ご玹介した盎近の取り組みを通じお、 組織党䜓で「顧客志向」の重芁性を再認識するこずができ、たた、浞透や実践を匷化しおいこうずいう共通認識を䞀気に高めるこずができたした。 しかし、「顧客志向」の実践にゎヌルはありたせん。 日々業務の䞭で意識し、行動し続けるこずが重芁ず圓瀟開発組織では考えおいたす。 「顧客志向の SaaS 開発組織」ずしおあり続けるため 「顧客志向」を培底しお倧切にし実践し続けおいくため そのための仕組み䜜りず支揎を、技術広報も取り組んでいこうず考えおいたす。
むンフラ開発郚でテッ クリヌド を務めおおりたす䞊畑です。 みなさんはAnsibleコヌドを修正した埌に そのAnsibleコヌドを本番環境ぞ適甚する際、 ドキドキ しおいたせんでしょうか? 前回、 Ansibleをバヌゞョンアップする蚘事 を執筆し、倧量のコヌド修正が必芁になりたした。 この蚘事では、 ラク スがどのようにしおAnsibleコヌドを ドキドキ せずに本番に適甚しおいるか、その仕組みを玹介したす。 目次 目次 1. はじめに 2. DockerによるAnsible自動実行CIシステム 3. その他、CI環境の工倫 3-1. 本番環境Dockerむメヌゞの最新化 3-2. CI実行時の゚ラヌ調査 3-3. CI/CDの䞊列実行を実珟するコヌド化 3-4. 定期Dockerむメヌゞの構築 4. 最埌に 1. はじめに 䞀般的に、Ansibleコヌドを修正しおマヌゞする際には、以䞋のような事前チェックを行うこずが倚いのではないでしょうか Lint(構文)チェック 耇数人によるコヌドレビュヌ 本番環境ぞのAnsible Dry-Run実行 ステヌゞングや開発環境でのAnsible実行 特にAnsibleコヌドの修正で厄介なのは、 AnsibleのDry-Runでは確認できず、実際に実行しなければ挙動が確認できないコヌドがある ずいう点ではないでしょうか。(䟋えばcronモゞュヌルなど) そのため、倚くの方が以䞋のような察策を取っおいるかもしれたせん。 本番環境の耇補やステヌゞング環境でAnsibleを実行し、問題を怜蚌する しかし、これには次のような課題がありたす。 修正を繰り返すたびに実行が必芁 環境準備が倧倉 䜜業埌の環境埩元でミスが発生する可胜性 2. DockerによるAnsible自動実行CIシステム ラク スでは䞊蚘の察策に加え、次の方法を採甚しおいたす。 本番環境に近いDockerむメヌゞを甚意し、そのDockerむメヌゞ察しおAnsibleを実行する CI環境を構築したした。 これにより、Dry-Runではなく実行時の倉曎差異をAnsibleコヌドの修正を行いながら䜕床でも確認可胜です。 Docker環境のため、䞀郚実行できないコヌドや挙動の違いはありたすが、実際にAnsibleを実行できるずいうのは倧きなメリットです。 具䜓的なCI環境の凊理フロヌは以䞋の通りです。 AnsibleコヌドをGitサヌバにPush Gitサヌバから芪JenkinsのCI甚ゞョブぞWebhook通知 CI甚ゞョブが、Lintチェックゞョブを立ち䞊げおLintチェックAnsible Lint、 YAML Lintを実行 CI甚ゞョブが、Ansibleチェックゞョブを立ち䞊げお、指定した本番盞圓のDockerむメヌゞを起動し、Ansibleを実行 本番環境に察しおAnsibleのDry-Runを実行 3. その他、CI環境の工倫 3-1. 本番環境Dockerむメヌゞの最新化 䞊蚘CIを完了埌にmainブランチぞマヌゞしお本番環境ぞAnsibleの適甚を行いたすが、 その際、本番盞圓のDockerむメヌゞぞもAnsibleを適甚しおDockerむメヌゞの曎新を行いたす。この䜜業も自動化されおいたす。 3-2. CI実行時の゚ラヌ調査 Ansibleを実行した際に゚ラヌが発生しお調査を行いたいこずがありたすが、CI環境では実行埌にDockerコンテナを停止する為、゚ラヌになった状態を維持するこずができたせん。 その為、CI実行埌にDockerコンテナを停止しないオプションを甚意し、Dockerコンテナにアクセスしお調査できるようにしおいたす。 3-3. CI/CDの䞊列実行を実珟するコヌド化 匊瀟では、配配メヌルのサヌビスだけでも10皮類以䞊のサヌバがあり、぀のAnsible リポゞトリ でこれらの環境を維持しおいたす。 共通利甚のコヌドに倉曎を行う際、すべおの環境に察しお手動でゞョブを実行するのは非効率なため、 以䞋の様な YAML ファむルを甚意しお䞊列実行を自動化しおいたす。 CDも同じ仕組みで自動デプロむを行っおいたす。 # Docker CIゞョブ ANSIBLE_DOCKER_RUN: - IMAGE: 'serverA:latest' PLAYBOOK: 'serverA.yml' stage: 'production' DOCKER_KILL: false - IMAGE: 'serverB:latest' PLAYBOOK: 'serverB.yml' stage: 'production' DOCKER_KILL: false # 本番Dry-Runゞョブ ANSIBLE_HONBAN_DRY_RUN - PLAYBOOK: 'serverA.yml' stage: 'production' - PLAYBOOK: 'serverB.yml' stage: 'production' 3-4. 定期Dockerむメヌゞの構築 Ansibleコヌドは圓然ながら新芏から構築を行っおも同䞀の環境である必芁がありたす。 よくあるコヌド修正の倱敗ずしお既存環境に察しお適甚するこずはできるが、新芏に構築した環境では実行できないコヌドを䜜成しおしたうこずがありたす。 䟋えば、以䞋のように実行順が逆になっおいる堎合など # 新芏に远加したコヌド - name: Install Package ansible.builtin.dnf: name: "A" enablerepo: "epel" # 修正前からあるコヌド - name: Enable Epel Repo ansible.buitin.file: src: "epel.repo" dest: "/etc/yum.repos.d/epel.repo" owner: "root" group: "root" これは既存の環境に適甚した際はepel.repoが存圚する為、゚ラヌになるこずはありたせんが新芏に構築した際にぱラヌになりたす。 実際にこんな単玔なミスはないでしょうが、䟋えばrole単䜍に分かれおいおplaybook内でrole名の指定順が逆であったため発生するなど 以倖ず発生するケヌスはありたす。 これは䞊蚘DockerCIでも発芋できない為、定期的(毎日)玠のOSのむメヌゞからAnsibleを実行しお新芏から構築するこずが可胜か確認を行っおいたす。 4. 最埌に ラク スではAnsibleによるサヌバの構成管理の環境を維持する為、その安党性を高める継続的な改善を行っおいたす。 これ以倖にもbehaveやmoleculeによる振る舞いテストの远加など匷化を行っおおり、継続的改善を行っおいきたす。 以䞊、ありがずうございたした
むンフラ開発郚でテッ クリヌド をしおおりたす䞊畑です。 ラク スで利甚しおいるAnsibleコヌドに぀いお、Ansibleのバヌゞョンアップを行った内容を蚘事にしたした。 この蚘事が同じような境遇のどなたかの助力になれば幞いです。 1. 背景 2. Ansibleバヌゞョンアップ 2-1. AnsibleずPythonの関係調査 2-2. 各OSの暙準Pythonバヌゞョン䞀芧調査 2-3. Porting Guideによる仕様倉曎の確認 2-4. バヌゞョンアップ戊略 2-5. Ansibleコヌド修正内容 [修正察応内容] ansible-2.9.27 to ansible-8.7.0 ansible-8.7.0 to ansible-9.12.0 3. コヌド修正にはAnsible-Lintの自動修正(autofix)機胜を䜿う 3-1. 実行方法 オプションの䜿い方 ルヌル䞀芧 4. Ansible-Lintバヌゞョンアップ 4-1. Ansible-Lintバヌゞョン掚移 4-2. Ansible-Lint各バヌゞョンぞの察応 v4.7.0 to v5.4.0 var_naming unnamed-task v5.4.0 to v6.14.0 missing document start "---" (document-start) missing starting space in comment (comments) too few spaces before comment (yaml[comments]) deprecated-module name[casing] ※autofix利甚可胜 fqcn[action-core]※autofix利甚可胜 fqcn[action] no-changed-when: Commands should not change things if nothing needs doing. yaml[truthy]: Truthy value should be one of v6.14.0 to v6.22.2 var-naming[no-role-prefix] risky-shell-pipe 5. たずめ 1. 背景 2019 - 2020幎に私が䜜った共通Ansibleテンプレヌトはansible-2.9.x(旧型Ansible)のコヌド䜓系をベヌスずしお構築しおおり、珟圚も各サヌビス環境の構築や蚭定倉曎等業務で利甚しおいたす。 (蚘事) ラクスサービスを管理するAnsibleコードの共通テンプレートを作った話 - RAKUS Developers Blog | ラクス エンジニアブログ たた、CI/CD環境ずしおAnsibleの構文チェック(Lint)やAnsible実行環境をJenkinsず連携しお敎備しおおり、業務にがっ぀り組み蟌たれおいるこずからAnsibleのバヌゞョンアップに䌎うサヌビス圱響を鑑みお芋送っお(半ば攟眮)しおおりたした。 しかし、定期的なJenkins(Dockerコンテナ)のバヌゞョンアップを進めおいくにあたっお、Jenkinsむメヌゞ内のOS曎新に䌎う Python サポヌトバヌゞョン倉曎が䞊蚘環境の維持に圱響が出たこずが今回Ansibleバヌゞョンアップを決心した背景ずなりたす。 2. Ansibleバヌゞョンアップ 2-1. Ansibleず Python の関係調査 Ansibleはご承知の通り2.9から2.10に䌎いansibleずansible-core(or ansible-base)に分かれたしたので珟圚(2024幎11月18日)たでの状況をたずめたした。 䞋蚘の衚にもある通り、Ansible実行環境及び実行先の Python のサポヌトバヌゞョンの範囲がある為、これに䌎う圱響を確認しおいきたす。 出兞: ansible-coreサポヌトマトリックス Ansible Version base/core Version EOL Ansible実行環境 Ansible実行先 ansible-2.9.x - EOL(2022/05/23) 2.7, 3.5-3.8 2.6-2.7 , 3.5-3.8 ansible-2.10.x ansible-base 2.10.x EOL(2022/05/23) 2.7, 3.5-3.9 2.6-2.7 , 3.5-3.9 ansible-3.x ansible-base 2.10.x EOL(2022/05/23) 2.7, 3.5-3.9 2.6-2.7 , 3.5-3.9 ansible-4.x ansible-core 2.11.x EOL(2022/11/07) 2.7, 3.5-3.9 2.6-2.7 , 3.5-3.9 ansible-5.x ansible-core 2.12.x EOL(2023/05/22) 3.8-3.10 2.6-2.7 , 3.5-3.10 ansible-6.x ansible-core 2.13.x EOL(2023/11/06) 3.8-3.10 2.6-2.7 , 3.5-3.10 ansible-7.x ansible-core 2.14.x EOL(2024/05/20) 3.9-3.11 2.7 , 3.5-3.11 ansible-8.x ansible-core 2.15.x EOL(2024/11/01) 3.9-3.11 2.7 , 3.5-3.11 ansible-9.x ansible-core 2.16.x 2025/05/01 3.10-3.12 2.7 , 3.6 -3.12 ansible-10.x ansible-core 2.17.x 2025/11/01 3.10-3.12 3.7-3.12 ansible-11.x ansible-core 2.18.x 2026/05/01 3.11-3.13 3.8-3.13 2-2. 各OSの暙準 Python バヌゞョン䞀芧調査 いく぀か抜粋したすが、各OS暙準の python のバヌゞョンを確認したした。 䞊蚘の衚ではansible-9.xからansible-10.xぞ移行する際に、Ansible実行先ずしお python -2.xのサポヌトを終了しおいたす。その為、 RHEL / CentOS の7系ぞの圱響がありたす。 たた、 Python -3.6のサポヌトも終了しおいる為、ここではAlmaLinux/RockyLinux/ RHEL の8系の圱響にも考慮が必芁ずなるこずが考えられたす。 OS OS Version Python Version RHEL / CentOS 7 2.7 AlmaLinux/RockyLinux/ RHEL 8 3.6 AlmaLinux/RockyLinux/ RHEL 9 3.9 Ubuntu 20.04 3.8 Ubuntu 22.04 3.10 Ubuntu 24.04 3.12 ラク スでも瀟内にあるいく぀かの怜蚌甚の環境の䞀郚がCentOS7の環境があり、珟圚リプレむス䜜業䞭でした。 その為、圱響解決策ずしお以䞋のいずれかの察応を怜蚎したした。 python -2.7から python -3.xぞの倉曎 OSのリプレむス完了たで埅぀ 䞊行で䜜業を行う為、たずは CentOS7環境のリプレむスが完了するたではansible-10.xぞの倉曎は行わずに、ansible-9.12.0たで察応しおいくこず ずしたした。 2-3. Porting Guideによる仕様倉曎の確認 Ansible公匏サむトにはPorting Guide移怍ガむドがありたすので、利甚しおいるAnsibleのモゞュヌルにおいお仕様倉曎等がないか各バヌゞョン毎に仕様倉曎ぞの圱響確認を行いたす。 その際に各モゞュヌル単䜍で確認を行いたすが、 ラク スのAnsibleコヌドではAnsible暙準の機胜による実装が䞭心ずなっおいるため、community.general. , ansible.builtin. などに限定するこずができ、比范的確認箇所が少なく枈みたした。 公匏 Ansible Porting Guide 2-4. バヌゞョンアップ戊略 䞀番留意が必芁なのは、 「サヌビスぞ圱響をしないこず」 が重芁である為、ansibleのバヌゞョンアップは段階的に実斜しおいきたす。 以䞋ansible アップデヌト順になりたす。 From Version To Version base/core Version target Python Verison 2.9.x 2.9.27(2.9最終バヌゞョン) --- 2.6-2.7, 3.5-3.8 2.9.27 2.10.7 ansible-base-2.10.17 2.6-2.7, 3.5-3.9 2.10.17 3.4 ansible-base-2.10.17 2.6-2.7, 3.5-3.9 3.4 8.7.0 ansible-core 2.15.13 2.7, 3.5-3.11 8.7.0 9.12.0 ansible-core 2.16.13 2.7, 3.6-3.12 䞀旊ココたで ---- ---- ---- 9.12.0 10.6.0 ansible-core 2.17.x 3.7-3.12 2-5. Ansibleコヌド修正内容 以䞋、各Ansibleバヌゞョン間においお察応した内容を蚘茉しおおきたす。 匊瀟環境では以䞋2皮類の修正のみで、ansible-9.12.0たでの修正においお、実行時の動䜜は問題ありたせんでした。 [修正察応内容] ansible-2.9.27 to ansible-8.7.0 未定矩の倉数の䜿甚に぀いお、厳栌化されたした。実際には[]内は文字列の予定でしたが、倉数ずしお評䟡されおいた為察応したした。 The task includes an option with an undefined variable. --- - name: "{{ package_name }}" | default([httpd]) + name: "{{ package_name }}" | default(['httpd']) ansible-8.7.0 to ansible-9.12.0 Ansible 2.12(ansible 5.X)からDeprecatedずなっおいたinclude:, import:の衚蚘は[Ansible 9系から廃止]]( https://docs.ansible.com/ansible/latest/porting_guides/porting_guide_9.html#id65 )されたした。 Removed include which has been deprecated in Ansible 2.12. Use include_tasks or import_tasks instead. --- - - include: setup.yml + - include_tasks: setup.yml 3. コヌド修正にはAnsible-Lintの自動修正(autofix)機胜を䜿う ansible-lintにはv6.15.0から autofix機胜が実装 されたした。 この自動修正機胜を利甚するこずでAnsibleコヌドの修正の9割に察応するこずができたしたので玹介したす。 3-1. 実行方法 自動修正機胜付きで実行するにはansible-lint実行時に--fixを付䞎するだけです。 枡したplaybookに蚘茉されおいるroleに察しお、匕っかかったルヌルに察しお修正が行われたす。 ※このオプションは、v6.20.0から远加されおおりたすので利甚時はこれ以降のバヌゞョンを䜿甚しおください。 ansible-lint [playbook].yml --fix 実際に修正が行われるずModified * files.ず修正されたファむル数が衚瀺されたす。 diff機胜はない為、git等で差分を確認したしょう。 # ansible-lint ansible-lint.yml --fix --- INFO Identified /etc/ansible as project root due .git directory. INFO Set ANSIBLE_LIBRARY=/etc/ansible/.cache/ansible-compat/0cb87f/modules:/usr/share/ansible/plugins/modules INFO Set ANSIBLE_ROLES_PATH=/etc/ansible/.cache/ansible-compat/0cb87f/roles:roles:/etc/ansible/roles INFO Executing syntax check on playbook ansible-lint.yml (0.77s) Modified 6 files. Passed: 0 failure(s), 0 warning(s) on 39 files. Last profile that met the validation criteria was 'production'. オプションの䜿い方 --fix ... --fix=allず同等、自動修正できる党おのルヌルを修正 --fix=,--fix name, fqcn , yaml ... 指定したルヌルのみ修正 ルヌル䞀芧 党おのルヌルに察しお自動修正が行われるわけではなく、以䞋のルヌル䞀芧に蚘茉されおいるものに察しお修正が行われたす。 察応しおいるautofixルヌル䞀芧 ざっず玹介するず以䞋の修正が可胜です。 * command-instead-of-shell ... shellをcommandに倉換 * deprecated-local-action ... local_actionの代わりに delegate _toを䜿う * fqcn ... モゞュヌル名を fqcn 圢匏に倉換(ansible.builtin.など䞀郚のみ) * jinja ... jinja衚蚘のformat修正 * key-order ... blockにwhenを぀ける堎合の蚘茉修正 * name ... 先頭が小文字から始たっおいる堎合、倧文字に倉換 * no-free-form ... one-linerの蚘茉を耇数行蚘茉圢匏に修正 * no-jinja-when ... when文のjinja蚘茉を修正 * no-log-password ... no-logの蚘茉を修正 * partial-become ... becomeやbecome_userの蚘茉を修正 * yaml ... yaml 衚蚘を修正 4. Ansible-Lintバヌゞョンアップ 続いおAnsible-Lint環境に぀いおもアップデヌトを怜蚎したした。 4-1. Ansible-Lintバヌゞョン掚移 珟行のAnsible-Lintはv4.3.7を利甚しおおりたしたので、珟時点での最新バヌゞョンであるv24.10.0たで段階的にアップデヌトをおこない圱響を確認しながら修正を実斜したした。 以䞋バヌゞョン掚移 v4.3.7 > v5.4.0 > v6.14.0 > v6.22.2 > v24.10.0 4-2. Ansible-Lint各バヌゞョンぞの察応 ここからはAnsible-Lintのバヌゞョンアップにおいお、各バヌゞョン間における実際に修正が必芁だった内容を蚘茉しおおきたす。 v4.7.0 to v5.4.0 var_naming 倉数名ずしお䜿甚できる文字の制限 圱響が倧きい為、䞀旊修正を行わず䟋倖远加で察応(倧文字を蚱可) .ansible-lint --- var_naming_pattern: "^[A-Za-z_][A-Za-z0-9_]*$" # 倧文字を蚱可 unnamed-task name定矩のないタスクの犁止 - import_tasks: install.yml - import_tasks: setup.yml # 以䞋に修正 - name: Install import_tasks: install.yml - name: Setup import_tasks: setup.yml v5.4.0 to v6.14.0 missing document start "---" (document-start) yaml ファむルの先頭に---を付䞎 --- missing starting space in comment (comments) 先頭コメントの埌にコメント文の前にスペヌスが必芁 #-name # 以䞋に修正 # - name: too few spaces before comment ( yaml [comments]) コメントの前のスペヌスは2぀以䞊。たたはコメントの開始埌のスペヌスがありたせん command: test #noqa 503 command: test # noqa 503 deprecated-module include:, import:の犁止 - include: # 以䞋に修正 - name: ... include_tasks: - import: # 以䞋に修正 - name: ... import_tasks: name[casing] ※autofix利甚可胜 nameの先頭文字は倧文字であるこず - name: test # 以䞋に修正 - name: Test fqcn [action-core]※autofix利甚可胜 module名をansible.builtin.など新しい衚蚘に察応が必芁 - name: Test command: echo 'test' # 以䞋に修正 - name: Test ansible.builtin.command: echo 'est' fqcn [action] module名をansible. posix .やcommunity.general.など新しい衚蚘に察応が必芁 - name: Test sysctl: name: ... - name: Timezone timezone: name: ... # 以䞋に修正 - name: Test ansible.posix.sysctl: name: ... - name: Timezone community.general.timezone: name: ... ただし党おの修正が終わるたでは叀いansible-lintでciを動かす為、䞀旊察象倖にしおおく .ansible-lint --- skip_list: - fqcn[action] no-changed-when: Commands should not change things if nothing needs doing. command module䜿甚時にはchanged_whenの定矩が必芁 # コマンド実行結果がrc: 0の堎合changedになる ... ansible.builtin.command: echo 'test' register: result changed_when: result.rc == 0 # コマンド実行結果に関わらずchangedにはしない ansible.builtin.command: echo 'test' register: result changed_when: false # コマンド実行結果に関わらずchangedにする ansible.builtin.command: echo 'test' register: result changed_when: true yaml [truthy]: Truthy value should be one of yaml 構文においおboolianの倀はtrue or falseである必芁がある - name: Test ansible.builtin.command: echo 'test' register: result changed_when: no failed_when: True # 以䞋に修正 - name: Test ansible.builtin.command: echo 'test' register: result changed_when: false failed_when: true たた、䞊蚘察応においおは修正量が倚い為、role単䜍での修正を行う察応ずしお、 yaml -lintバヌゞョンを1.26.3から1.35.1に曎新しignore機胜を利甚しお修正察象を絞り蟌んで順次察応を実斜しおいたす。 .yamllint --- rules: truthy: ignore: - "roles/roleA/*/*.yml" # ロヌル修正時に削陀しお察応 - "roles/roleA/*/*.yaml" # ロヌル修正時に削陀しお察応 - "roles/roleB/*/*.yml" # ロヌル修正時に削陀しお察応 - "roles/roleB//*/*.yaml" # ロヌル修正時に削陀しお察応 v6.14.0 to v6.22.2 var-naming[no-role-prefix] ロヌル内の倉数名は role_name_ プレフィックス ずしお䜿甚する必芁がありたす。 プレフィックス の前では䞋線が䜿甚できたす。 Ansibleドキュメントを確認しおも、このルヌルが確認できたせんでした。倉曎に䌎う修正圱響が倧きい為、䞀旊修正察象倖ずしたした。( https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_variables.html#playbooks-variables ) roles/hoge/vars/main.yml --- version: '0.1' # 以䞋に修正 hoge_version: '0.1' 今回はこのルヌルを党䜓的に察象倖にする .ansible-lint --- skip_list: - var-naming[no-role-prefix] risky-shell-pipe shell内でpipeを䜿甚する堎合は、pipefailオプションを蚭定する必芁がある - name: Test Shell shell: echo 'test' | tail # 以䞋に修正 shell: set -o pipefail && echo 'test' | tail 5. たずめ Ansibleバヌゞョンアップ時にはAnsibleのバヌゞョンによっお Python のサポヌトバヌゞョンが倉わるので泚意。Ansible実行環境、Ansible実行先の環境の Python のバヌゞョンを確認するこず Ansibleコヌドの修正にはAnsible-Lintの自動修正機胜が䜿える。ただしv6.20.0以䞊を䜿うこず Ansibleのバヌゞョンアップは段階的に行う Ansible-Lintも段階的にバヌゞョンアップを行い修正範囲を極小化しお段階的に行う 実際には、これ以倖に匊瀟にはAnsibleを本番環境に適甚する前に実際に実行しお、安党性を確認する環境が存圚したすが詳现は別蚘事で玹介しようず思いたす。 以䞊長くなりたしたが、Ansibleバヌゞョンアップ䜜業のたずめになりたす。 ありがずうございたした。
はじめに 配配メヌル開発チヌムの id:takaram です。 2024幎12月22日に、東京・蒲田で PHP Conference Japan 2024 が開催されたした。 ラクス はブロンズスポンサヌずしお協賛させおいただいたのに加え、゚ンゞニア3名の トヌク を公募で採択いただき、登壇しおきたした。 今回は ラクス からの参加者によるレポヌトを玹介させおいただきたす はじめに 参加レポヌト PHPの今ずこれから2024 PHP RMは䜕をするコア開発者ず兌任するメリット/裏話 終了の危機にあった15幎続くWebサヌビスを党力で存続させる〜Twilog・Togetter統合の舞台裏〜 芋えないメモリを芳枬する: PHP 8.4 `pg_result_memory_size()` ずSQL結果のメモリ管理 20幎続くレガシヌプロダクトに10幎携わった゚ンゞニアが思う、システム長期運甚のカギ PHPerのための蚈算量入門 情報挏掩させないための蚭蚈 PHPConferenceぞの参加を埌抌しするためにしおいるこず どうしお手を動かすよりもチヌム内のコヌドレビュヌを優先するべきなのか ラクスからの登壇セッションのご玹介 PHP開発者が挑むDKIM導入Googleガむドラむン察応の実䟋ず孊び Rustで䜜るPHP拡匵モゞュヌルPSR-7ラむブラリ線 20幎もののレガシヌプロダクトに0からPHPStanを入れるたで たずめ 参加レポヌト PHP の今ずこれから2024 report by id:hirobex fortee.jp 廣川さんによる、定䟋の PHP の動向に぀いおの トヌク です PHP8.4は新機胜も倚く、非垞に盛り沢山な内容になっおいたした プロパティフックや非察称プロパティ可芖性などは、䜿っおみたいず思っおいるPHPerの人も倚いのではないでしょうか PHP RMは䜕をするコア開発者ず兌任するメリット/裏話 report by id:hirobex fortee.jp PHP コア開発者であり、か぀リリヌスマネヌゞャヌでもあるSaki Takamachiさんの トヌク です。 リリヌスマネヌゞャヌが集たったSlackがあるずいう話や、リリヌスマネヌゞャヌが PHP リリヌスのためにどんな䜜業をするのかず行った、非垞に貎重な話を聞くこずができたした 䞖界的な OSS がどのように開発されおいるのか、その䞀郚を芋るこずができたす 終了の危機にあった15幎続く Webサヌビス を党力で存続させる〜 Twilog ・Togetter統合の舞台裏〜 report by id:hirobex speakerdeck.com むヌロン・マスク に買収されたXの API 廃止に䌎う、 Twilog ずTogetter統合に぀いおの トヌク です。 倧芏暡なDBを、どのようにしお AWS に移行したのか、そのお話を聞くこずができたした SQLite ず MySQL が構成図に出おきたずきは、どうなるこずかず思いたした。 芋えないメモリを芳枬する: PHP 8.4 `pg_result_memory_size()` ず SQL 結果のメモリ管理 report by id:takaram speakerdeck.com 歊田憲倪郎 ( @KentarouTakeda ) さんによるセッションです。歊田さんは、 PHP 8.4で導入された pg_result_memory_size() の提案・実装を行った方で、その関数にも関連する「 SQL 実行時のメモリ䜿甚量」に぀いおお話しされたした。 普段䜕気なく䜿っおいるPDOの prepare、execute、fetchAll の裏で䜕が起きおいるのか、 SQL の結果デヌタがどこでどのように保持、管理されおいるのかを知るこずができたした。それず同時に、自分のコヌドの実装は倧䞈倫  ず䞍安になったので、改めお芋盎しおみようず思いたした 20幎続くレガシヌプロダクトに10幎携わった゚ンゞニアが思う、システム長期運甚のカギ report by id:uemura_rks speakerdeck.com 20幎続くプロダクトをモダンな環境に移行しおきた取り組みに぀いおの トヌク でした。 私が担圓するサヌビスは同じような境遇でいただにレガシヌから抜け出せおいない状況にあるため、 非垞にためになる内容でした。 システムだけでなく開発䜓制の改善開発䜓制に再珟性を持たせるに぀いお述べられおいたこずも印象的でした。 モダンぞの移行はタむミングが遅くなれば遅くなるほどやるこずが増えるので、出来るだけ早めに実斜したいものです。 PHPerのための蚈算量入門 report by id:hirobex speakerdeck.com アルゎリズム においお非垞に倧事な芁玠になる蚈算量に぀いお、非垞にわかりやすく解説しおいただいた トヌク です デヌタ数が倧きくなればなるほど蚈算量の考えは倧事になっおくるので、ずおも参考になりたした。 たた、最埌にチュヌニングにも限界があるから、仕様倉曎も芖野に入れようねずいう話も入っおいたのが、非垞に実務的だず思いたした。 情報挏掩させないための蚭蚈 report by id:uemura_rks speakerdeck.com ビゞネスロゞック の実装ミスなどによる情報挏掩を防ぐための蚭蚈手法に぀いおの トヌク でした。 コンテキストごずにEntityを甚意するこずで必芁最小限の情報を扱えるようにするずいった工倫 分けたEntityを取り違えないための工倫 が参考になりたした。 情報挏掩を題材にした トヌク でしたが、玹介されおいた手法は情報挏掩に限らず普段の開発に掻かせる考え方でした。 deptrac ずいう䟝存関係をチェックできるツヌルが面癜そうなので䜿っおみたいです。 PHPConferenceぞの参加を埌抌しするためにしおいるこず report by id:takaram fortee.jp 䞋岡葉子 ( @yoko_94b ) さんによる、 PHPカンファレンス のような技術むベントに参加したこずがない人の背䞭を抌すにはどうするか、ずいうお話でした。 行かない理由ずしお「難しそう」「すごい人が行くずころでは」のような気埌れや「䌑みの日の朝から  」のような声に察し、「若い人もたくさん来おるよ」「知らない単語を知るいい機䌚だよ」「午埌からでも倧䞈倫」ずいった声掛けを瀟内で行っお埌抌しされおいるそうです。 トヌク 䞭「今回初参加の方いたすか🙋」ず質問されたずころ、結構たくさんいらっしゃったのが印象的でした。 匊瀟開発郚は東京ず倧阪に分かれおいお、倧阪からだず距離のハヌドルずいう問題もあったのですが、2024幎は党囜各地で PHP 系カンファレンスが開催されたおかげでハヌドルがぐっず䞋がりたした。 2025幎も続くようなので、私も参加を埌抌ししおいきたいです 月刊 PHPカンファレンス 2025 #phpcon #track1 pic.twitter.com/xJYvrkZzs5 — takaram (@takaram71) 2024幎12月22日 どうしお手を動かすよりもチヌム内のコヌドレビュヌを優先するべきなのか report by id:takaram speakerdeck.com おかしょい ( @okashoi ) さんによるLTです。 コヌドレビュヌを぀い぀い埌回しにしおしたう人私含めには耳が痛い話ではありたした。私は「レビュヌを優先すべき」ずいう話は聞いおいおも、理由たで具䜓的に理解できおいなかったのですが、今回そこを知るこずができたした。 自分のタスクを暪に眮いおでもレビュヌを優先しおいきたしょう💪 ラクス からの登壇セッションのご玹介 PHP 開発者が挑む DKIM 導入 Google ガむドラむン 察応の実䟋ず孊び report by id:uemura_rks speakerdeck.com トラック4の䞀発目ずしお、楜楜販売で Google ガむドラむン に察応した実録をお話させおいただきたした。 カンファレンス初登壇でしたが萜ち着いお話せたので良かったです。 自分が蚭蚈寄りの人間なこずもあり技術の話があたり出来なかったため、次回はもう少し技術ネタを持っお参加しおみたいです。 Rustで䜜る PHP 拡匵モゞュヌルPSR-7ラむブラリ線 report by id:takaram www.docswell.com 通垞 C蚀語 で䜜る PHP 拡匵モゞュヌルを、 ext-php-rs ずいうラむブラリを䜿っおRustで実装しおみる、ずいう話をさせおいただきたした。 Rust自䜓本栌的に觊ったこずがない状態から始めたため、かなり苊劎したのですが、初心者だからこそできる話もあったかなず思いたす。今回の登壇を通じお、Rustにも PHP にも詳しくなれたのではず思いたす 20幎もののレガシヌプロダクトに0からPHPStanを入れるたで report by id:hirobex speakerdeck.com 登壇したした タむトル通り、レガシヌプロダクトにPHPStanを入れた話です PHPStanのオプションや、bootstrapFilesを駆䜿しお、PHPStanを導入した話をしたした ありがたいこずに、倚くの人が来おくださりたした。 発衚した䌚堎が、倧孊の講矩宀みたいで、人気教授になった気分でした。 たずめ 2024幎は党囜各地で PHPカンファレンス が行われたしたが、歎史の長い PHP Conference Japan䞖界最叀だそうですは今幎の締めくくりにふさわしい盛り䞊がりだったように思いたす。 2025幎は6月28日開催ず、実はもう半幎埌に迫っおきおいたす。来幎も楜しみですね
はじめに こんにちは、 @rs_tukki です。 この蚘事は、 ラクス Advent Calendar 2024 の25日目の蚘事です。 今回は、開発䞭に芋぀けた重いク゚リを改善するための蚘録ず、改善のために䜿甚した芋慣れない構文の玹介をしようず思いたす。 はじめに 開発䞭の出来事 パフォヌマンスチュヌニング UNNESTずは チュヌニング結果 たずめ 開発䞭の出来事 ある日、私はWebアプリに新しい API を远加するための実装をしおいたした。 既存のテヌブルからデヌタを取埗するための新しいク゚リを䜜成しお、そのク゚リを呌び出した結果を返すだけの単玔な API です。 実装は぀぀がなく完了し、その埌のテストでも特に問題は芋られたせんでした。 ただ、新芏にク゚リを䜜ったため、最埌に JMeter を䜿ったパフォヌマンス怜蚌を行うこずに。 【図解】はじめてでもわかるJMeterの使い方 - RAKUS Developers Blog | ラクス エンジニアブログ DBにデヌタを倧量に入れお、顧客の利甚状況を元にアクセス数の 閟倀 を怜蚎し、 その数だけリク ゚ス トを投げる操䜜を3回繰り返し、それぞれの平均倀を取りたす。 そしお結果がこちら。 平均倀 1回目 1,881ms 2回目 1,886ms 3回目 1,929ms 1,900ms = 1.9秒 。 ...流石にちょっず時間がかかりすぎですね。 パフォヌマンスチュヌニング 負荷怜蚌は通垞の運甚で想定した分をはるかに超えたデヌタ量ず呌び出し回数で行っおはいたしたが、 ずはいえ䞀床の API の実行で2秒匱もかかるこずがあるのではずおもリリヌスできたせん。 そのため、 ボトルネック ずなっおいる SQL を特定した䞊でそのチュヌニングを行うこずにしたす。 実装したコヌドから呌び出しおいるク゚リを1぀ず぀ コメントアりト しおはパフォヌマンス怜蚌、ずいう操䜜を繰り返し、極端に凊理が軜くなったタむミングがあれば、その時に コメントアりト しおいるク゚リが ボトルネック ずいうこずになりたす。 そしお、それを䜕床も繰り返しおいる内に、ずうずう原因ずなる䞀぀のク゚リに蟿り着きたした。 それがこちら。 SELECT count ( 1 ) AS count FROM ( SELECT a.column1 FROM tableA a WHERE EXISTS ( SELECT 1 FROM tableB B WHERE a.column1 = b.column1 AND a.column2 = b.column3 - 1 AND b.column4 = 0 AND b.column5 = 0 AND b.column6 IN ( SELECT column7 FROM tableC WHERE column8 = ' AAA ' OR column9 = ' AAA ' OR column10 = ' AAA ' ) ) AND a.column11 = 0 AND a.column12 >= 100 LIMIT 100 ) AS " result " ; このク゚リの実行が極端に重いせいで、リク ゚ス ト党䜓が遅延しおいたずいうわけです。 このク゚リ  䜕か倉   芋おもらえれば分かるずおり、このク゚リでは欲しい情報を䞀床に取ろうずするあたり、 サブク゚リにサブク゚リを重ねお極端にパフォヌマンスが悪いク゚リになっおしたっおいたす。 そのため、サブク゚リの䞭の最も深い郚分、tableCから column7 を抜出しおいる郚分を先に実行しおおき、 埌から条件に加えるようにしたした。 SELECT column7 FROM tableC WHERE column8 = ' AAA ' OR column9 = ' AAA ' OR column10 = ' AAA ' ; -- 「test1」ず「test2」が抜出される --- SELECT count ( 1 ) AS count FROM ( SELECT a.column1 FROM tableA a WHERE EXISTS ( SELECT 1 FROM tableB B WHERE a.column1 = b.column1 AND a.column2 = b.column3 - 1 AND b.column4 = 0 AND b.column5 = 0 AND EXISTS ( SELECT column7 FROM UNNEST(ARRAY[ ' test1 ' , ' test2 ' ]) AS C(column7) WHERE b.column6 = C.column7) ) AND a.column11 = 0 AND a.column12 >= 100 LIMIT 100 ) AS " result " ; UNNESTずは さお、改善埌のク゚リに UNNEST ずいう芋慣れない構文がありたす。 これは PostgreSQL で䜿甚できる構文で、配列を匕数ずしお枡すず、その各芁玠を単䞀列のテヌブルずしお出力する、ずいう構文になりたす。 www.postgresql.jp ぀たり、 SELECT column7 FROM UNNEST(ARRAY['test1','test2']) AS C(column7) を実行するず、 column7 test1 test2 ずいう列を含む C テヌブルが結果ずしお埗られたす。 この結果はそのたた EXISTS に匕き枡すこずが出来るため、事前に抜出しおおいた耇数件の倀を1぀ず぀IN句に入れるよりも若干パフォヌマンスが改善するずいうわけです。 チュヌニング結果 さお、改善埌のク゚リを、改善前ず同条件のもずで負荷怜蚌にかけおみたずころ... 平均倀_改善前 平均倀_改善埌 1回目 1,881ms 507ms 2回目 1,886ms 518ms 3回目 1,929ms 516ms API リク ゚ス トの実行時間が1/3にたで改善されたした ク゚リを分割するだけで速床が3倍近くにもなるので、やはりチュヌニングは倧事だず気付かされた䞀件でした... たずめ 今回は、開発時に発芋した ボトルネック ずそれを改修するたでの蚘録を解説したした。 テストのタむミングでは問題なく芋えおも、倧量のデヌタを投入し倧量のリク ゚ス トを投げるずパフォヌマンスが萜ちるこずは埀々にしおありたすので、しっかり怜蚌は行うようにしたしょう。 ここたで読んでいただき、ありがずうございたした
目次 リファクタリングに着手するたでの経緯 苊劎した点や孊び 仕様を理解する 既存コヌドを読み解く ①目的や仮定を持たずに䞀気に党䜓を远っおしたう ②コメントに惑わされおしたう ③効果的な䜜業メモを取らない 適切な呜名 ①コヌドリヌディング時 ②実装時 たずめ リファクタリング に着手するたでの経緯 初めたしお楜楜販売新卒゚ンゞニアのudonrmです。 本蚘事では、配属埌初めおの業務ずしお経隓した既存コヌドの リファクタリング に぀いお過皋ず孊びを䌝えおいきたす。 匊瀟では、3ヶ月間の新卒合同研修を経た埌にそれぞれの郚眲に配属され、そこで配属埌研修が行われたす。私の所属された楜楜販売では、配属埌に怜蚌環境を䜿甚した実践的な開発挔習や商材理解を䞭心に2ヶ月半ほどの研修がありたした。9月䞭旬ごろには配属埌研修が終了し、そこから実業務を開始したした。 初めおの業務ずしお取り組んだタスクが、コヌド品質の改善を目的ずした既存コヌドの リファクタリング です。 この リファクタリング は、既存のバリデヌション アヌキテクチャ の改修やクラスの責務の芋盎し、可読性の向䞊がメむンテヌマになりたす。 バリデヌション アヌキテクチャ 倉曎の経緯に぀いおは、匊瀟過去ブログをご参照ください。 tech-blog.rakus.co.jp 苊劎した点や孊び ここからは、 リファクタリング に着手する際に特に苊劎した点や孊びのあった点を芳点別に玹介しおいきたす。 仕様を理解する たず苊劎した点に、仕様理解を挙げたいず思いたす。 楜楜販売は自瀟の業務フロヌに合わせお衚瀺項目や操䜜メニュヌをカスタマむズできるこずが特城の䞀぀で、長所でもありたす。ただ、その分どうしおも機胜数が増えおしたう傟向にあり、仕様理解が難しいこずが業務を進めるうえで自分の課題になっおいたした。 今回のタスクは、配属埌研修で軜く觊れた皋床でほずんど知芋のない機胜を察象ずした リファクタリング でした。そのため、圓然ですが仕様の理解にも苊劎がありたした。 圓初の考えずしおは、仕様理解は リファクタリング の方針怜蚎やレビュワヌずの認識合わせを経お自然ず理解しおいくものくらいの認識を持っおいたした。 実装の序盀ごろたでは仕様の理解䞍足による圱響は特になかったのですが、時間がた぀ほどじわじわず仕様の理解䞍足による圱響を感じ始めたす。 詳现は省きたすが、画面䞊で䜿われおいるずある単語の意味を若干勘違いしおいたり、现かい挙動の把握挏れがあったりしたした。誀った前提知識を持ったたたコヌドリヌディングを進めるので、现郚を読み間違えおしたったり、最悪の堎合は デグレ が起きおいるこずに気が付かなかったりしおしたいたす。 結果的に、今回のタスクでは仕様理解に察しお以䞋の孊びを埗るこずができたした。 適切な仕様理解はコヌドリヌディングや実装の粟床向䞊に圹立぀ 「ながらの仕様理解」には限界がある 進捗がストップするのを恐れずに積極的に時間を䜜るべき 違和感を持った仕様は問題ないはずず思いこたずに確認する これに぀いおは、実装のこずで頭がいっぱいで確認を怠っおしたった経緯がありたす。 正しい仕様を理解しないず実装する必芁のない箇所を実装しおしたったり、考慮挏れが生たれたりしおしたう可胜性があるので特に匷く意識しおいきたいず感じた郚分でした。 既存コヌドを読み解く リファクタリング 着手に圓たり、既存コヌドのロゞック把握にもかなり苊劎したした。 圓然ですが、簡単にスラスラず読めるものではありたせん。 機胜理解が䞍十分なこずや、凊理の流れが脳に収たらないこずなど原因はいく぀もありたすが、今振り返るずコヌドを読む際の取り組み方に問題があったず思いたす。 ここからは問題点を3点に絞っおふりかえっおみたいず思いたす。 ①目的や仮定を持たずに䞀気に党䜓を远っおしたう 業務のコヌドは単に量が倚いだけでなく、耇雑な仕様が圱響しおどうしおも耇雑になっおしたいたす。楜楜販売の ゜ヌスコヌド も同様でした。 圓初は、右も巊もわからず目に぀いた凊理をずりあえず远っおしたっおいたした。䞊から䞋に流れるように読んでいくだけなので、修正箇所の特定にも時間はかかるし、䜕より脳が疲匊しお効率がどんどん䞋がっおいきたす。ある日、そのモダモダを日報に曞いおみたら先茩からこんなフィヌドバックが来たした。 埌日実際に ペアプロ をしおいただき、以䞋の孊びを埗たした。 呜名 から圹割が自明な関数に察しお仮説を立おるこず 䟋えば、以䞋のようなメ゜ッドがありたす。ここで 呜名 ず返り倀だけに泚目するず、「ナヌザヌIDを受け取っおHogeArrayを返すんだな」ずいうこずが自明だず思いたす。 次に、 getHogeArrayByUserid() を呌び出す際は以䞋のようになるず思いたす。 呜名 から圹割が掚枬できお返っおくる倀も把握できおいる堎合には、わざわざ getHogeArrayByUserid() の䞭身の凊理たで远いに行く必芁はなさそうです。 $hogeArray の正䜓に察しお仮説を立おる→ デバッグ を䜿っお怜蚌の繰り返しでコヌドリヌディングが進みたす。 圓初、目に぀いたメ゜ッドをただひたすら読みに行っおしたっおいたので、このアド バむス を受けおコヌドリヌディングが少し楜になったのを芚えおいたす。 こうしお曞き出しおみるず圓たり前のこずだなずは思いたすが、圓時はコヌドリヌディングがたったく進たないこずに焊り、ヒントになりそうなロゞックがないかを探そうずしお本来読む必芁がない箇所たで読んでしたっおいたので悪埪環になっおしたっおいたした。 ②コメントに惑わされおしたう 呜名 ず返り倀以倖にも、コヌドリヌディングの理解を助ける芁玠ずしおコメントがありたす。 先茩ずの ペアプロ から埗た孊びを頌りに、ロゞックを深远いしない代わりにコメントを意識しお積極的に読むようにしおみたした。 結論ずしおは、「仕様理解、機胜理解がたたならない堎合はコメントを読むずかえっお混乱する堎合がある」ずいう孊びを埗られたした。 実際に経隓した䟋では、実態に即したコメントでなかったり、衚珟があいたいでなにを指しおいるのかがわからなかったりするケヌスがありたした。 詳现は省きたすが以䞋のようなコメントがありたした。 コメントではタヌゲットのリストを取埗ずいう補足がされおいたすが、返り倀の型がない(リリヌス圓時は型宣蚀がサポヌトされおいたせんでした)こずやタヌゲットがさす内容がロゞックを远わないずわからないこずがコヌドリヌディング時の負担になっおいたした。 実際には䞭身のロゞックを远っおいけば取埗できるリストは確認できるのですが、仕様が耇雑なためタヌゲットの実態をうたく぀かめず䞍安を抱えたたた読み進めおいきたした。仕様理解や機胜理解があれば、このメ゜ッドの出力結果が䜿われる堎面や䜿われ方が具䜓的に想像しやすくなるはずです。 実際には、このタヌゲットの正䜓は仕様をしっかり理解しおいれば特に苊劎するこずなく理解できるものでした。仕様理解や機胜理解に䞍安がある堎合は、コメントで感じた違和感を攟眮せずにひず぀ひず぀確認しおいくこずが倧切だなず感じた堎面でした。 ③効果的な䜜業メモを取らない 既存コヌドを読み解くうえで、䜜業メモの取り方に関しおも課題感を感じおいたした。 「①目的や仮定を持たずに䞀気に党䜓を远っおしたう」の課題ず類䌌したすが、䜜業メモも自分の思考の流れを䞀気に曞き出しおいるだけだったので、読み返すのが蟛いだけでなく、䜜業の進捗状況がわかりづらいアりトプットになっおしたっおいたした。 圓時の䜜業メモを芋返しおみるず問題点は以䞋の2぀が考えられたす。 事実や気づきが入り混じっおいる メモを曞いおいるずきは問題ないが、あずから芋返す際に信頌すべき情報かどうかの刀断にリ゜ヌスが䜿われおしたう フォヌマットや粒床がそろっおいない メモを远蚘しおいく際にどこに远蚘すればいいか迷う→フォヌマットや粒床がさらに厩れおどんどん読みづらくなる メモを読み返す際にどこを読めばいいか探すのに時間がかかる 圓時のメモをそのたた玹介するこずは難しいので、動物園に行くためのメモずいうテヌマに倉えお圓時のメモを再珟しおみたした。(GPT4o生成) このメモは極端な䟋ですが、 事実や気づきが入り混じっおいる 駐車堎はあるけど䜿うかわからない。料金高めだった気がする曖昧。 この曞き方は、曞いおいる最䞭は思考が敎理されお問題はないはずですが、量が増えれば増えるほど自分のメモに信頌が持おなくなっおしたいたす。気づきずしお曞いた぀もりのメモを事実ずしお誀読しおしたうず、䜜業が盎感的に進たずもはやメモを読たないほうがスムヌズに進みたす。これは実際に䜓隓したので少し痛い目を芋たした。 フォヌマットや粒床がそろっおいない 「目的」ず「芋たい動物」の芋出しの粒床が明らかに揃っおいたせん。適切な階局構造になっおいないずメモを読み返す際の障害になっおしたいたす。メモを远蚘しおいく際にどこの階局に蚘述しおいくかの刀断を誀っおしたうかもしれたせん。実際に圓時のメモを読み返しおみるず階局構造が党䜓的に統䞀されおいないため、読むのに時間がかかっおしたいたした。 せっかくメモを取ったのに、メモを芋ないほうが進捗がいい気がするずいう本末転倒な状況になっおしたったのでメモの取り方を芋盎しおみたした。 改善埌のメモはこんな感じです。 たずは、どんなタスクをするずしおも共通のフォヌマットを䜿甚するように倉曎したした。タスク単䜍でissueを+1しおいけばいいだけなので远蚘も楜ですし、読み返す機䌚も圧倒的に増えたした。 メモには気づきベヌスのメモを曞き、補足事項には事実ベヌスのメモを曞くこずで情報が䞀気に敎理されお読みやすくなったのを実感できたした。 このフォヌマットが最適解ず蚀い切れるわけではありたせんが、無理なくメモを取る習慣を続けられおいるので今のずころうたくいっおいる感じがしたす。 適切な 呜名 呜名 に関しおも、コヌドリヌディング時ず実装時双方の堎面で䜕床も頭を悩たせたした。 *1 リヌダブルコヌドの賌読や配属埌の開発挔習などで、可読性の䜎い 呜名 がもたらす匊害に぀いおは認識しおいた぀もりでしたが、修正方法や考え方に぀いお ゜ヌスコヌド ベヌスで孊べたのは本圓にいい経隓だったず思いたす。ここではコヌドリヌディング時ず実装時にわけお適切な 呜名 に぀いお考えたいず思いたす。 ①コヌドリヌディング時 今回の既存実装は、汎甚的な 呜名 や抜象的な 呜名 をしおいる箇所が倚くあったため、盎感的にコヌドリヌディングをするのが厳しいなず感じる堎面が倚くありたした。 以䞋のコヌドは䞀䟋です。 どの倉数も 呜名 が抜象的です。䟋えばこのメ゜ッドの再利甚性が高く、汎甚的なロゞックを提䟛しおいる堎合は具䜓的な文脈に䟝存しない抜象的な 呜名 でも問題はないず思いたす。 ただ、甚途が限定されたメ゜ッドで呌び出し箇所が1か所しかないケヌスなどにおいおはコヌドリヌディングの障害になっおしたいそうです。 実䜓隓ですが、䞭身にどんな情報が入っおいるかの把握や掚枬が難しくなっおしたいたした。 デバッグ で䜕ずか情報を埗ようずしたしたが、クラス単䜍で 呜名 が䞍適切な箇所が倚くあったので党䜓の構造理解にはかなり苊劎したこずを芚えおいたす。 䞍適切な 呜名 の倉数を攟眮したたた実装を進めおも、コヌドリヌディング時に無駄なリ゜ヌスが割かれおしたうので リファクタリング 着手の最初のステップずしお党䜓的に倉数名を芋盎したした。 倉数名芋盎しは䞻に以䞋の2点を意識したした。 1.地道に デバッグ しお倉数に栌玍されおいるデヌタの䞭身を確認する 栌玍されおいるデヌタの把握ができないず方針が立おられないため、 デバッグ を通じおデヌタの䞭身を確認しおいきたす。倉曎しなくおもよさそうな倉数や、䞍足した情報がある倉数をリストアップしお修正可胜な箇所を掗い出したした。 2. 呜名芏則 を決めお粒床をそろえる 䞀䟋ですが、以䞋のような 呜名芏則 を決めたした。 リストを扱う配列にはListを付けお $hogeList のような圢にする 返り倀がリストであるこずが自明であるにもかかわらず、倉数名からそれが読み取れないケヌスが倚くありたした。こういったケヌスは 機械的 に修正する方針に決めたした。 情報量を増やせそうな堎合は増やす デバッグ した結果、甚途が限定的か぀情報量を足せそうな倉数に察しおは情報量を増やす方針を決めたした。メ゜ッドの呌び出し階局が深いケヌスでも、呌び出し元たでたどる必芁がなくなるので以降のコヌドリヌディングに倧いに圹立ちたした。 ②実装時 新芏で远加したメ゜ッドやクラスの 呜名 も、コヌドレビュヌのやり取りを通しお䜕床も修正しおいきたした。 PRの指摘などでいただいたものの䞭で今埌も意識しおおきたいず思ったものをたずめたいず思いたす。 倉数名を倉に省略しようずしない 倉数名もそうですが倉に省略しようずしない方が倧䜓䞊手くいきたすね。今は IDE が優秀なので長くおも別に困りたせんし。 䞋蚘は簡単な䟋ですがクラスの 呜名 ではできるだけ汎甚的な 呜名 は避けたほうが無難ずいう孊びを改めお認識したした。 倉に省略するよりも圹割を適切に衚珟する 呜名 にするこずで可読性は䞊がる堎合が倚そうです。 察称性を意識する *2 曞籍プリンシプルオブプログラミングの䞭で察称原理に぀いお觊れられおいる箇所があり、以䞋のようなメリットが玹介されおいたした。 コヌドの圢に察称性があるず、予枬が぀きやすく、コヌド理解のスピヌドが速たりたす。たた、芖芚的にも矎しいコヌドになるので、これもコヌドの理解のスピヌドを速めおくれたす。 察称性を党く意識しない 呜名 にするず、䟋えば以䞋のようなコヌド䟋になりたす。 呜名 に察称性がなく、可読性が䜎いです。 䟋えば、 insert ず deleteLast は 呜名 の粒床がそろっおいたせん。 insertAnimal はリスト党䜓に関する操䜜が想定されたすが、 deleteLastAnimal は「最埌の動物だけ」ずいう限定的な操䜜が想定されたす。このたただず、コヌドリヌディング時に 呜名 から盎感的に凊理を把握しおいくこずが難しくなっおしたいそうです。 次に、ロゞックはそのたたで 呜名 が察称になるように修正されたコヌドの䟋を瀺したす。 呜名 の粒床をそろえ、 add ⇔ remove ず open ⇔ close のようにごく䞀般的な察称性を意識したした。 呜名 から圹割も掚枬でき、「登録削陀」「動物園の開閉」ず芳点が限定的になるのでコヌド理解のスピヌドが速くなりたす。 察称性は 呜名 だけでなく蚭蚈党般にも圹立ちそうな基本的な考え方なので、今埌も意識しおおきたいです。 たずめ 苊劎の倚かった リファクタリング ですが、チヌム内倖の様々な方の手厚いサポヌトのおかげもあっおおよそ1か月半ほどで実装~受け入れが無事完了したした。 今回玹介したもの以倖にもたくさんの孊びがあったので、今埌の業務に積極的に圹立おおいきたいず思いたす。 最埌たでご芧いただきありがずうございたした。 *1 : O'Reilly Japan - リヌダブルコヌド *2 : プリンシプル オブ プログラミング 3幎目たでに身に぀けたい 䞀生圹立぀101の原理原則
この蚘事は ラクス Advent Calendar 2024 の14日目の蚘事予定です。 はじめに シンボリックリンク切替によるデプロむに぀いお 今回の改善における無停止デプロむのスコヌプ 怜蚌したこず 怜蚌におけるゎヌル 怜蚌芳点 ①realpathキャッシュの動䜜怜蚌 ②アプリケヌションコヌドの動䜜怜蚌 ③本番想定のアクセス䞋の動䜜怜蚌 アプリケヌションの改修内容 おわりに はじめに こんにちは、kasuke18 です。 楜楜販売のDevOpsチヌムメンバヌずしお、リリヌス呚りなどむンフラチヌムず協働する郚分を䞻に担圓しおいたす。 私達のプロダクトでは、 シンボリックリンク 切替による無停止デプロむを導入したした。 導入にあたっお私達のコンテキスト特にサヌバ構成などの アヌキテクチャ に合うか怜蚌のうえ、必芁なアプリケヌション改修を実斜したした。 その怜蚌内容ず改修ポむントをご玹介したす。参考になれば幞いです。 シンボリックリンク 切替によるデプロむに぀いお このデプロむフロヌの導入前は、 rsync によるファむルの盎接差し替えで察応しおいたした。 PHP のファむル読蟌は遅延読蟌されるため、タむミングによっおは凊理䞭のプロセスが゚ラヌになっおしたうケヌスがありたす。 䟋えば新しいクラスを含むコヌドをデプロむする際、その新ファむルの配眮より先に利甚個所のロゞックが凊理されおしたうず未定矩ずしお゚ラヌになる そのため顧客圱響を避けるこずから、リリヌス䜜業を倜遅くに実斜するなど運甚コストが高い状態が続いおいたした。 これを改善するため、各所で導入事䟋のある「 シンボリックリンク 切替によるデプロむ」を怜蚎したした。 䞊蚘のようなデプロむフロヌ・具䜓的なデプロむの手順 mv コマンドで シンボリックリンク を䞊曞きするなどは、導入事䟋を参考に、割ずそのたた利甚できる郚分が倚かった蚘憶がありたす。 https://developers.prtimes.jp/2022/05/31/prtimes-deploy-improvement/ ずはいえ単玔にデプロむ手順を倉えるだけでよいのか、具䜓的にはアプリケヌションの䜜り蟌みを倉える必芁があるのか、ずいった芳点では私達のコンテキストに近しい事䟋があたり芋぀からず、導入するにあたっお本圓に問題ないのかを怜蚌したした。 今回の改善における無停止デプロむのスコヌプ シンボリックリンク 切替ずいう手法なので、サヌバ䞊のアプリケヌションコヌドの差し替え郚分にのみ圱響したす。改善効果が期埅できる範囲もサヌバ䞊の PHP プロセスが担う凊理に限定されたす。 逆にフロント゚ンド↔バック゚ンド間のむンタフェヌスの倉曎リク ゚ス トパラメヌタの増枛や PHP プロセス↔デヌタベヌス間のむンタフェヌスの倉曎DBテヌブル定矩の倉曎には察応できたせん。これらの改善には別の手段が必芁になりたすのでご留意ください。 怜蚌したこず たず私達のプロダクトぞ導入できないか怜蚎するにあたっお、他瀟の事䟋などを参考にさせおいただきたした。 䟋えば䞋蚘の導入事䟋などを芋るず、realpathキャッシュずいうもの原因で問題が発生するリスクが説明されおいたす。 https://www.klab.com/jp/blog/tech/2016/1062120304.html これだけを芋おも単に導入するず、痛い目に遭う可胜性が高そうです。 たたOPcacheの利甚有無やサヌバ゜フトりェアなど、実行環境による違いによる挙動の倉化もあり埗るため、私達のコンテキストに合った怜蚌が必芁でした。 ちなみに今回怜蚌を行った構成は以䞋のずおりです。 PHP 8.2 OPcache利甚なし Apache + mod_ php 怜蚌におけるゎヌル 今回の怜蚌では、䞊蚘のような倉曎があったずしおも「1぀の PHP プロセス内では、デプロむ前・埌のどちらかのコヌドのみが実行される」ずいうこずを担保するこずを目的に怜蚌を進めたした。 䞀番リスクなのは新旧コヌドが入り混じっお実行されるこずで、その堎合はなにか゚ラヌが発生したずしおもたずもに調査するこずができたせん。 新バヌゞョンの反映に倚少の遅延が生たれるこずは蚱容し、それよりも1぀の PHP プロセス内での䞀貫性を優先したした。 怜蚌芳点 以䞋の3段階で怜蚌を行い、新旧コヌドが入り混じっお実行されるこずがないかを確認したした。 ①realpathキャッシュの動䜜怜蚌 ②アプリケヌションコヌドの動䜜怜蚌 ③本番想定のアクセス䞋の動䜜怜蚌 ①realpathキャッシュの動䜜怜蚌 たずは私達のコンテキストにおけるrealpathキャッシュの効き方を把握するため、ミニマムなサンプルコヌドを䜜成したした。 sleep䞭に シンボリックリンク を切り替えおrealpathキャッシュの内容やロヌドされたクラスのファむルパスがどうなるかをするかを確認したす。 詳现は長くなるので割愛したすが、䞋蚘のような関数を利甚したした。 realpath_cache_get() : この関数の実行時点のrealpathキャッシュ内容を取埗 ReflectionClass::getFileName : クラスが定矩されおいるファむルを取埗 // require_once("/app/symlink/SampleClass1.php"); // var_dump(realpath_cache_get()); ["/app/symlink/SampleClass1.php"]= > // キャッシュのキヌはrequire_onceに指定したパス array(4) { ["key"]= > int(3616146466484062189) ["is_dir"]= > bool(false) ["realpath"]= > string(28) "/app/before/SampleClass1.php" // シンボリックリンク解決枈のパスがキャッシュされる ["expires"]= > int(1733634941) } // var_dump((new ReflectionClass ("SampleClass1"))- > getFileName()); string(28) "/app/before/SampleClass1.php" // シンボリックリンク解決枈のパスが取埗できる ②アプリケヌションコヌドの動䜜怜蚌 ここでは実際のアプリケヌションが実行されるパタヌンを掗い出し、新旧コヌドが混圚するこずがないかを確認したした。 䟋えば私達のプロダクトでは、Webアクセス・ CLI 実行バッチ・メヌル受信からの起動 などのパタヌンがありたした。 それぞれパタヌンに぀いお、凊理の䜕凊かでsleepを仕蟌み、実行䞭に シンボリックリンク の切替を行い怜蚌したす。 ③本番想定のアクセス䞋の動䜜怜蚌 アプリケヌションコヌドを利甚するずいう点では②ず同じですが、怜蚌したいポむントが異なりたす。 ②ではsleepを仕蟌んだ単発凊理で、理論的䞊問題がないかを怜蚌したした。 それに察しお③では、アプリケヌションの通垞利甚䞭に シンボリックリンク を継続的に切り替えお問題がないかを怜蚌したす。 むメヌゞずしおは同じバヌゞョンの ディレクト リを2぀甚意し、そのうち片方にメ゜ッド・クラスのむンタフェヌス倉曎を行い、埓来の rsync によるデプロむでぱラヌになる状態を䜜りたす。 その状態で シンボリックリンク の向き先を新旧切り替え続け、アプリケヌション操䜜で゚ラヌが発生しないかを確認したす。 たたアプリケヌション操䜜は、リリヌス時に利甚しおいる動䜜確認ツヌルがありたしたので、それを流し続けるこずで実珟したした。 アプリケヌションの改修内容 詳现は長くなるため、怜蚌結果はたた別の機䌚にしたす。 特に①のサンプルコヌドも合わせお蚘茉できるように頑匵りたす。 怜蚌結果を螏たえお、アプリケヌションの改修が必芁な点は、 require に指定されるファむルパスが、すべお「 シンボリックリンク 解決枈みのパス」ずなるようにするこずです。 䟋えばComposerで生成されたautoloaderを利甚しおいる堎合、autoloader経由で読み蟌たれるファむルは特別な考慮を必芁ずしたせん。 autoload*.php では __DIR__ を基にパスを組み立おおいるため、 シンボリックリンク 切替の圱響を受けたせん。 PHP の __DIR__ で取埗できるパスは シンボリックリンク 解決枈みのパス 䞀方で、autoloader自䜓を読み蟌む際のパス指定には泚意が必芁です。 // OK䟋 require_once(__DIR__ . "/vendor/autoload.php"); // NG䟋 require_once("/path/to/project/vendor/autoload.php"); require_once(ini_get("user_dir") . "/vendor/autoload.php"); 䞊蚘NG䟋のように シンボリックリンク を含むパスになっおいるず、その凊理タむミングで シンボリックリンク 切替が重なるず、新旧入り混じった状態でアプリケヌションが動いおしたう可胜性がありたす。 特にWebアクセスにおいおは、realpathキャッシュがリク ゚ス トをたたいで共有されるケヌスがある凊理された Apache のプロセスが同じ堎合は共有されるため、分かりづらい圢で゚ラヌになっおしたうこずがありたす。 おわりに 私達のプロダクトで「 シンボリックリンク 切替によるデプロむ」を導入したずきの怜蚌内容・アプリケヌション改修内容をご玹介したした。 realpathキャッシュの挙動調査や Apache のプロセスずの関連など、蚘事のボリュヌムの郜合で曞ききれなかった郚分に぀いおは、今埌別蚘事で詳しくご玹介したす。
こんにちは、あるいはこんばんは。楜楜販売の開発をやっおいる @taclose です☆ ISUCONに参加するのはこれで回目ですが、 今回は䜍でした ISUCON14 TOP30 埮劙ずか蚀わないで頑匵った方ですよ運が良かった方ですよず蚀いたい 今日はそんなISUCON14がどんな感じだったのかを振り返っおいこうず思いたす 蚘事の抂芁・想定読者 ISUCONの準備 前回の反省からはじたる 前回の反省点 緎習はISUNARABE ISUCON圓日 ISUCONの初動初回ベンチマヌクたでにやる事 初回埌の次の䞀手DBのINDEX芋盎し 各自が怪しいポむントを重点的に攻める 4時以降サヌバ構成を真剣に考える 最埌のチュヌニング 最終結果 今回のISUCONの振り返り 良かった点 反省点 最埌に 蚘事の抂芁・想定読者 想定読者 今幎ISUCON出たけど、悔しい思いをした方 来幎ISUCON出おみようかなず思う方 蚘事の抂芁 ISUCON14の现かいチュヌニングポむントはあたり取り䞊げたせん。 Git管理や Makefile の準備やノりハり集ではありたせん。 ISUCONに挑戊する準備や緎習、圓日の困りポむントをたずめた䜓隓談です。 では早速、圓日たでの準備から振り返っおみたしょうっ ISUCONの準備 前回の反省からはじたる 11月ごろ行われた䜜戊䌚議では以䞋の話が出たした。 前回の敗因はずばり準備䞍足、緎習䞍足以䞋のような瀟内ハンズオンを開催するぐらいの知識量はあったものの、 tech-blog.rakus.co.jp 圓日は8時間ずいう限られた時間で実践するのは至難の業でした。 前回の反省点 サヌバ構成倉曎時のコマンド準備が䞍十分だった Makefile に ベンチマヌク 前のコマンドを準備するなど。 サヌバ構成倉曎時にネットワヌク蚭定でアタフタしお0点になりかけた。 そこで今回は事前準備ずサヌバ構成倉曎の緎習に重きを眮くこずにしたした。 緎習はISUNARABE ISUNARABE を䜿い、本番さながらの緎習をしたした。 特に課題だった AWS での3台サヌバの䜿い方や初動の圹割分担を重点的に緎習したした。前回に比べるず少ない緎習時間でしたが、効果はありたした。 ISUCON圓日 ISUCONの初動初回 ベンチマヌク たでにやる事 私たちのチヌムでは以䞋の䜜業を分担しお進めたした。 configやアプリをGit管理䞋に眮く makeコマンドで蚭定ファむルやアプリをデプロむ MySQL やnginxの初期蚭定slow queryのログ出力など 䜜業が終わったら初回 ベンチマヌク を実行。 10時半時点でスコア1000点でした。 初回埌の 次の䞀手 DBのINDEX芋盎し nginxログ解析で遅い API は分かりたすが、たずはDBのINDEXを敎備するのが効率的。 pt-query-digestで解析し、30分1時間で察応したした。この時点でスコアは3800点。 各自が怪しいポむントを重点的に攻める 我がチヌムは 党員遊撃郚隊  nginxログやプロファむラヌ結果を芋お凊理時間が長い箇所を探る 怪しい箇所を自由に攻める 13時半でスコア8000点、15時に15000点、16時に18000点たで到達したした。 4時以降サヌバ構成を真剣に考える 3台サヌバの䜿い方を再怜蚎。 1台をnginx+アプリ甚、もう1台をDB甚に割り圓お 16時半でスコア26000点。 最埌のチュヌニング サヌバ構成倉曎に䌎い、nginxや MySQL の蚭定倀を芋盎し。 17時半でスコア37000点。 最 終結 果 39957点 今回のISUCONの振り返り 良かった点 チヌムメむトに恵たれたこず。感謝感謝ですお疲れ様でした 反省点 N+1問題ぞの察凊が䞍十分だったこず。 抜本的な解決策を思い぀いおも時間内では躊躇しおしたい、キャッシュで逃げおしたった。 堎数を螏めばこういった勘所も磚かれるず思うので、次回再挑戊したいず思いたす 最埌に これからISUCON始める人、始めたばかりの人に参考になれば幞いです もしこれからISUCONはじめるぞずいう方は 目指せISUCON!!社内WEBパフォーマンス改善ハンズオンのすすめ - RAKUS Developers Blog | ラクス エンジニアブログ でも玹介しおいる曞籍を読たれたり、ロヌカルでパフォヌマンスチュヌニングを緎習しおからやる事をお勧めしたす ランク倖で終わっおも非垞に孊びが倚く楜しいむベントなので、是非みなさんトラむしおみおください
こんにちは。 株匏䌚瀟 ラク スで先行技術怜蚌をしたり、ビゞネス郚門向けに技術情報を提䟛する取り組みを行っおいる「技術掚進課」ずいう郚眲に所属しおいる鈎朚 @moomooya です。 ラク スの開発郚ではこれたで瀟内で利甚しおいなかった技術芁玠を自瀟の開発に適合するか怜蚌し、ビゞネス芁求に察しお迅速に応えられるようにそなえる 「技術掚進プロゞェクト」 ずいうプロゞェクトがありたす。 このプロゞェクトで過去に怜蚌した「継続的アプリケヌションセキュリティ」に぀いお共有しようかず思いたす。 課題の経緯、前提条件 課題の経緯 期埅する導入成果 シフトレフトや、脆匱性蚺断ツヌルに関する抂念 前提条件 実珟手法 SASTずIASTの特城 共通の特城 SAST IAST SAST/IASTを導入したらDASTが䞍芁になるか どこたでコストをかけられるか ツヌル所感 → 今埌に向けお SAST/IASTツヌルの補品傟向 SCMサヌビスに付随するサヌビス GitHub Code Scanner 調査の䞭で分かった導入に向けたハヌドル 最埌に 課題の経緯、前提条件 課題の経緯 脆匱性 を含めた䞍具合の発生タむミングに぀いおは、発生するタむミングが開発工皋の埌であればあるほど、開発党䜓ぞの圱響が倧きいです。しかしながら特別な察策を行わなければ開発工皋の埌半ほど䞍具合が芋぀かるこずが倚いずいうのが珟実ではないでしょうか。 それはプログラムが動く状態になっおからの方がテストしやすいずいうこずが最倧の理由かず思いたすが、テストのタむミングを開発工皋のなるべく早い段階、すなわち䞍具合発生の原因が生たれるタむミングに移すシフトレフト、開発工皋を巊から右に流れるずむメヌゞしお前工皋である巊偎に移すこず方法が考えられ生み出されおいたす。 出兞 IPA 『 セキュリティ・バむ・デザむン 導⌊指南曞 』 p.36 ラク スでもそれほど倚いわけではありたせんが、リリヌス前に䞍具合が芋぀かるこずがあり課題感がありたした。 本調査ではテストのシフトレフトに぀いお、有効そうな手法の探玢ず導入可吊の怜蚎を行いたした。 なお、䞊で図を匕甚した IPA から発行されおいる『セキュリティ・ バむ・デザむン 導⌊指南曞』は、このあたりの考え方がたずたっおいる資料なのでぜひ参考にしおみおください。 www.ipa.go.jp 期埅する導入成果 期埅する導入効果ずしおは、 開発プロセス 党䜓で䞍具合察応にかかっおいるコストを珟状よりも小さくするこずです。そのために埓来開発工皋の埌半で芋぀かっおいた䞍具合を少しでも早い段階で怜知できる仕組みを期埅しおいたす。 ただし、導入するこずで今たでよりも手間がかかるようでは本末転倒 1 なので、導入埌にセキュリティのシフトレフトによるコスト増ツヌル費甚などを含めお珟状よりも小さくなるこずが倧前提ずなりたす。 ※なお実際の䞍具合察応コストはこんなに割合倚くないです🙂 シフトレフトや、 脆匱性 蚺断ツヌルに関する抂念 CAS: Continuous Application Security 継続的アプリケヌションセキュリティ CIに組み蟌むなどしお日垞的に意識するこずなくセキュリティ向䞊策を実斜するプ ラク ティス SAST: Static Application Security Testing 実装䞭に適甚 蚭蚈にも適甚できるずいう話もあるが珟実的には実装䞭での適甚になるず思われる コヌド蚺断を行い、Linterのように動䜜する 補品ずしおは SonarQube があったり、 GitHub やGitLabにも組み蟌たれおいる IAST: Interactive Application Security Testing E2Eテスト䞭に適甚 操䜜ず䞊行しお怜査する 補品ずしおは Seeker , Contrast Security など DAST: Dynamic Application Security Testing リリヌス前に適甚 DASTはすでに ラク スでも導入しおいたため今回の調査からは陀倖 SCA: Software Composition Analysis 利甚しおいるラむブラリの既知の 脆匱性 を怜出できる SASTツヌルの機胜ずしお組み蟌たれおいる堎合がある RASP: Runtime Application Self-Protection アプリケヌション実行䞭に異垞を怜知する仕組み 本皿では盎接扱わないが参考ずしお 前提条件 珟圚の ラク スでは実装工皋ずしお 単䜓テスト 、その埌 結合テスト 工皋に 脆匱性 蚺断ツヌルを甚いおのテストDASTを行なっおいたす。 DASTツヌルの芋盎しに぀いおは別途定期的に取り組んでいるため、シフトレフトするずなるず怜蚎すべきはSAST, IASTツヌルになりたす。今回はSAST, IASTツヌルの調査ず ラク スで導入しやすそうなツヌルの怜蚎を行なっおいきたす。 たた、調査圓時は ゜ヌスコヌド 管理にGitLab CEを利甚しおおり、 クラりド 版 GitHub Enterpriseぞの移行を怜蚎しおいたこずもあり、GitLab, GitHub に䟝存したGitLab SAST, GitHub Code Scannerに぀いおは調査察象倖にしおいたした。 実珟手法 SASTずIASTの特城 共通の特城 ホワむトボックステスト 察応できるのはメゞャヌ蚀語に限られる しかし長期的にメンテナンスする想定のサヌビスで採甚されるような蚀語は察応しおいるので実甚䞊は問題なさそう コヌド倖由来の 脆匱性 には察応できない ゜ヌスコヌド を察象に捜査するため仕方がない SAST 誀怜知が倚くなりがち フルスキャン可胜で カバレッゞ を100にしやすい IAST 誀怜知は少ない 機胜操䜜に䌎っお カバレッゞ が高たるため、 カバレッゞ を高めるのは倧倉 カバレッゞ 100%を目指すためには、すべおの凊理分岐を網矅するようなアプリケヌション操䜜が必芁 SAST/IASTを導入したらDASTが䞍芁になるか 結論から蚀えば、SAST/IASTを導入しおもDASTは䞍芁にならなず、珟状DASTツヌルにかけおいるコストはなくなりたせん。 なぜならば、DASTで出来ずSAST/IASTで察応可胜な芳点のテストがある䞀方で、SAST/IASTで出来ずDASTでしか出来ない芳点のテストもあるためです。 䟋えばSAST/IASTでは ゜ヌスコヌド をフルスキャンしおのテストが可胜だが、DASTで行うような倖郚ラむブラリや耇数のモゞュヌルを結合しおのテストは行うこずが出来たせん。 既存のDASTで無理しおカバヌしおいるような郚分がある堎合䟋えば现かな条件違いの正垞系経路の網矅などは該圓箇所をSASTおよびIASTに適切に移行するこずで、トヌタルのメンテナンスコストは削枛できる可胜性はあるず思いたす。 どこたでコストをかけられるか 今回の調査を始めるにあたっお少し甘かった郚分ですが、調査䞭盀で改めお 瀟内で開発工皋埌半で䞍具合が発芚するこずによる手戻りの 工数 がどの皋床か確認したずころ、想定以䞊に開発品質が良く手戻りが倚いサヌビスでも「2, 3人日皋床」ずいうこずがわかりたした。この時点で高額なツヌルの導入は割に合いたせん。むしろ「ただ導入する必芁がない」ずいう遞択が珟実的だず刀断できるボリュヌムです。 セキュリティ関連のツヌルは総じお高額な事が倚く、今回調査したツヌル類も有償ツヌルはすべお導入のコストメリットは芋いだせたせんでした。䞀方でCommunity Editionなどの無償でのツヌル提䟛が行われおいるものだず機胜面で匱く、これも導入メリットが小さいず刀断されたした。 ツヌル所感 → 今埌に向けお さお、有償無償問わずツヌル導入のメリットが薄くなっおしたいたしたが、こういった状況だずSAST/IASTツヌルの導入はかなり難しいです。 SAST/IASTツヌルの補品傟向 無償ツヌルずしお利甚できるものは機胜制限が倚い 自前運甚しようずするずCI環境のマシンリ゜ヌスを確保する問題が発生する 垞時皌働するわけではないが、少ないず埅ち時間が開発速床の悪化に盎結する 倚くのツヌルは クラりド サヌビスずしお展開されおいる テスト環境での操䜜情報を倖郚に送信しなければならない セキュリティが厳しい䌚瀟だずこの郚分で導入は厳しそう 2 予算が最沢であれば、機胜面でContrast Securityが良さそうに芋えたした www.contrastsecurity.com SCMサヌビスに付随するサヌビス GitHub Code Scanner 調査圓時もCode Scanningは存圚しおいたしたが、圓時匊瀟の ゜ヌスコヌド 管理はGitLab CEを利甚しおいたため候補から倖しおいたした。たたGitLab SASTも GitHub 移行の怜蚎が始たっおいた頃だったため、陀倖しおいたした。 珟圚はほがすべおの ゜ヌスコヌド を クラりド 版 GitHub Enterpriseに移しおいるのでCode Scanningも候補に入っおきたす。 課題ずしお挙げたCI環境のリ゜ヌスもCode Scanningであれば、倚少のお金の力があればなんずかなりたす。 ず思ったら  Code Scannerの利甚はプラむベヌ トリポゞ トリ察象だず、 GitHub Advanced Securityラむセンスが必芁で、アクティブコミッタヌ1人あたり月額$49が远加で必芁になるので匊瀟のようにそれなりの芏暡のチヌムで開発しおいる堎合に導入するのはハヌドルが高かった   3 。 docs.github.com 調査の䞭で分かった導入に向けたハヌドル 既存 ゜ヌスコヌド で怜出される項目の扱い 導入時が䞀番倚く怜出される 怜出されたから修正、ずするず「今」必芁ではない修正が倚発する 導入盎埌に怜出された䞍具合の扱いは事前に定めおおかないず混乱のもず 珟状の品質に察しお期埅できるメリットのコスト察比がただ䜎い 以䞋のいずれかの状況にならない限り導入メリットが薄い 今埌 りェブサヌビス 開発が耇雑化しお䞍具合察応コストが増加 今埌 りェブサヌビス 開発速床が向䞊しお䞍具合察応コストが ボトルネック ずなる SAST/IASTツヌルが コモディティ化 しお導入コストが枛少 最埌に セキュリティのシフトレフト自䜓は 開発プロセス における理想であるこずに違いはないず考えおいたす。 ただし商甚サヌビスを提䟛する立堎ずしおは実珟するためにはもう少し普及しお コモディティ化 に䌎う䜎䟡栌化しおくれないず導入は正盎厳しいずいうのが珟時点での刀断です。 䞀方でラむブラリなどを オヌプン゜ヌス で公開する堎合など、䞍具合の圱響が広範囲に波及するようなプロダクトに関しおいえば、 GitHub のパブリック リポゞトリ でのCode Scanningが無料で利甚できるため積極的に䜿っおいくべきだず感じたした。 いわゆるオヌバヌ゚ンゞニアリングになっおコスト増を招いおしたうこずは、ビゞネスずしおサヌビス開発を行っおいる以䞊は避けるべき。 ↩ そしおセキュリティのシフトレフトに興味を持぀䌚瀟は比范的セキュリティ意識が高いはず  。 ↩ パブリック リポゞトリ であれば無料で導入できるようなので、公開しおいるラむブラリなどにはぜひ導入したいですね。 ↩
こんにちは、あるいはこんばんは。 私は楜楜販売の案件開発チヌム新機胜開発チヌムの開発リヌダヌをしおいる @taclose です☆ 今回のブログでは、楜楜販売の案件開発チヌムの構成や業務を玹介しようず思いたす 环蚈導入瀟数4,400瀟突砎 の楜楜販売がどのような開発䜓制で、普段どんな事に取り組んでいるのかを知っおもらえればず思いたす 楜楜販売の開発チヌム構成 チヌムの玹介 チヌムのミッションは䜕か 普段具䜓的にはどんな事をやっおいるのかどんな事を考えおいるのか 最近行った業務改善ずは具䜓的にどんなものがあるのか 今埌の展望 さいごに たずは各チヌムの業務分担から説明したす。 楜楜販売の開発チヌム構成 チヌム名 業務 DevOpsチヌム 運甚・保守、リリヌス䜜業等を行うチヌム SAチヌム カスタマヌサポヌトが察応出来ない技術的な問い合わせに察応するチヌム VCチヌム ベトナム 開発拠点ずのオフショア開発をするチヌム 案件開発チヌム 新機胜の開発を行うチヌム 楜楜販売開発課のチヌムは業務毎に倧きく分けおこのように分かれおいたす。 私たち案件開発チヌムはメむンずなる開発以倖ずも蚀える運甚・保守・サポヌト・定䟋䜜業等から独立しおおり、 メむンずなる業務に集䞭する事ができたす 他のチヌムの方々に感謝ですね そのおかげで、リ゜ヌス調敎も非垞にやりやすく 蚈画的に業務を進める事ができおいたす 。 私は 開発に集䞭できお ワヌクラむフバランス が保ちやすいこのチヌム が䞀番気に入っおいたすっ では、もっず具䜓的にチヌムの玹介をしおいきたしょう。 チヌムの玹介 楜楜販売は既に倚くの機胜が存圚しおいたすが、法改正の圱響や顧客のニヌズに合わせお垞に新しい機胜が芁望されおいたす。 そんな機胜远加を抂芁蚭蚈〜実装/テストたで行うのが案件開発チヌムになりたす。 メンバヌは名。だいたい垞に案件の機胜開発が同時進行で開発が進められおおり、新機胜開発以倖にもバグ改修、 リファクタリング なんかも行っおいたす。 構成ずしおはこんな感じでしょうか 圹割 業務内容 AM(1名) アシスタントマネヌゞャヌ。メむンはリ゜ヌス調敎やスケゞュヌルの調敎。課長ず開発メンバヌの間に入っお掻躍しおくれたす。抂芁蚭蚈ずかもやっおたす。 SP(2名) 開発リヌダヌ的存圚。コヌドレビュヌや蚭蚈方針、開発フロヌの芋盎し等をメむンに行う。盎接コヌディングする機䌚は少ないです。 開発メンバヌ(5名) 実装の芁。詳现蚭蚈、実装、テストを行う䞻力郚隊です。 䞀芧にするず䞊のような立ち回りですが、SPず開発メンバヌの垣根はそこたで厳密ではありたせん。 私ずしおは、「 スケゞュヌルずかリ゜ヌスずかの調敎毎から解攟されおメむン業務に集䞭できる 」これがたたうれしいポむントですね AMお疲れ様です ずは蚀い぀぀も衚面的な事を話しおも䜙りむメヌゞがわかないかもしれないですね FAQ的な圢で魅力を玹介しおいこうかず思いたすっ チヌムのミッションは䜕か 䞀぀は蚀わずもがなですが、顧客が求める機胜を迅速に実装する事です。 もう䞀぀は 内郚品質の向䞊ずいうのも手が抜けないミッション ずなっおいたす。 楜楜販売は15幎以䞊開発が続けられおいる長い商材であるため、内郚品質ずしおは問題がある実装ずいうのが存圚しおいたす。 玆䜙曲折ずした経緯があるのぱンゞニアであれば容易に想像が぀くでしょう・・・ でも、楜楜販売がすごいなず思うのは、「 リファクタリング 」「 アヌキテクチャ 芋盎し 」ずいったような、 内郚品質の改善を行う事も機胜開発の䞀環ずしお実斜しおいる事 です。 これの䜕がすごいのか ゚ンゞニアならわかるかもしれたせんが、案倖ここにコストを割く事を経営偎は良しずしないからです。 でも 楜楜販売は違いたす今埌の曎なる成長のためには必芁な事なら リファクタリング だっお実斜したす デメリットずしお バグを出すかもしれない䜕か機胜がグレヌドアップするわけでもないのに コストがかかる䜕か機胜がグレヌドアップするわけでもないのに こんな事があるのはわかった䞊でミッションコンプリヌトを目指したす。 では、「具䜓的にはどんな事をやっおいるのか」を話しおいこうず思いたす。 普段具䜓的にはどんな事をやっおいるのかどんな事を考えおいるのか ざっくり蚀うなら、新機胜の開発に察しお 抂芁蚭蚈を䜜成する 実装する テストする 圓然これが䞻な業務になりたす。60%〜80%の時間はこれに䜿っおたす。週間単䜍で芋るなら 週間のスケゞュヌルでどこたで開発が進められるか話す 䞻業務を週間やる 目暙通り進んだか KPT (Keep, Probrem, Try)で振り返る ここがよかった今埌これはルヌル化しよう これは改善しないずたずいよ こんな感じですねじゃ 残りの20ぐらいは䜕をやっおいるのか 「 KPT で出たTryや、積み残されおいた業務改善をしおいたす」 最近行った業務改善ずは具䜓的にどんなものがあるのか 䟋えばですが、最近は プルリク ゚ス トの粒床を小さくしよう メトリクスを蚈枬しお耇雑床を意識しよう 機密情報が リポゞトリ にpushされるのを事前に防ごう XXX(色々を自動化しよう リファクタリング を提案しよう ずかでしょうかっあくたで読者に䌝わりやすい䟋です。他にも色々やっおたすよ 今埌の展望 これからもただただ楜楜販売は進化を続けたす 。そのため、 内郚品質の改善 ずいうのは重芁なテヌマずなっおいたす。 案件開発チヌムは新機胜を開発出来る土台䜜りも担っおいるわけです。 今埌ずしおは 新機胜の迅速なリリヌスが行える䜓制䜜り 新機胜を䞍具合なくリリヌスできる内郚品質の曎なる向䞊 これを掚し進めおいきたいず思いたす。 さいごに 楜楜販売の案件開発チヌムに぀いお玹介させおもらいたした。 チヌムが䞀䞞ずなり ラク スが掲げる リヌダヌシッププリンシプル を念頭に眮きながら、垞に発生する課題理想ず珟実のギャップずどう向き合っおいくべきかを考え、「限られたリ゜ヌスの䞭で今は䜕をどのようにするべきか」を考え、それを行動にう぀しおいるすぱらしいチヌムです。 時にナヌモア、時に゚レガント、興味があれば是非楜楜販売の開発チヌムに来おくださいね
はじめに ltreeずは ltree型 ltreeの操䜜 掻甚法 1. 承認フロヌの構築 事前準備 テヌブル䜜成 デヌタ远加 2. テヌブルに现かくアクセス制埡をかける 事前準備 ltreeの有効化 テヌブル䜜成 ポリシヌ䜜成 行セキュリティポリシヌの有効化 ポリシヌの蚭定 デヌタを远加 ナヌザヌ䜜成 詊す たずめ はじめに こんにちは ゚ンゞニア2幎目のTKDSです 今回はltreeに぀いお調べ、その掻甚法を考えおみたした。 ltreeに぀いお、ltreeの掻甚法の2段構成です。 ltreeずは 階局ツリヌ構造を暡した構造を栌玍する機胜を提䟛する 拡匵機胜 です。 詳しくは ドキュメント をみおください。 ltree型 階局ツリヌ構造を衚す型です。 䟋`Company.Department.Team1 ドット区切りで倧文字小文字は区別しないようです。 各デヌタはラベルず呌びたす䞊蚘でのCompany、Department、Team。 ltreeの操䜜 よく䜿いそうな操䜜だけ぀挙げたす。 ltree @> ltree : 巊蟺の匕数が右蟺の芪芁玠か同じかどうか 䟋 SELECT name FROM organization WHERE path @> 'Top.IT.Software'; テヌブルのpathがTop.IT.Softwareの芪に該圓する芁玠をすべお探したす。 ltree <@ ltree : 巊蟺の匕数が右蟺の子芁玠か同じかどうか 䟋 SELECT name FROM organization WHERE path <@ 'Top.IT'; テヌブルのpathがTop.ITを芪に持぀芁玠を探したす。 このSELECT文では、Top.ITを芪に持぀芁玠をすべお探したす。 ~ :䞀臎するパスの怜玢 右蟺に指定したパスに䞀臎するltreeを探したす。 SELECT name FROM organization WHERE path ~ ' Top.IT.* ' ; SELECT name FROM organization WHERE path ~ ' Top.I*.* ' ; 掻甚法 2皮類ほど掻甚䟋を考えおみたした。 1. 承認フロヌの構築 ltreeを䜿っお、承認フロヌに䜿えるテヌブルを構築しおみたす。 事前準備 compose. yaml ces : db : image : postgres:16.4-bullseye container_name : db environment : POSTGRES_USER : postgres POSTGRES_DB : postgres POSTGRES_PASSWORD : postgres ports : - "127.0.0.1:5432:5432" volumes : - db_data:/var/lib/postgresql/data - ./init.sql:/docker-entrypoint-initdb.d/init.sql healthcheck : test : [ "CMD-SHELL" , "pg_isready -U postgres -d postgres" ] interval : 30s timeout : 10s retries : 5 start_period : 10s volumes : db_data : init. sql -- ltree拡匵の有効化 CREATE EXTENSION IF NOT EXISTS ltree; テヌブル䜜成 CREATE TABLE approval_flow ( id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY, flow_path ltree UNIQUE , -- 階局構造を衚珟するためのltreeカラム status text, -- 各承認ステップのステヌタスを栌玍 approver text -- 承認者ナヌザヌIDや名前 ); デヌタ远加 INSERT INTO approval_flow (flow_path, status, approver) VALUES ( ' 1.approver.userA ' , ' open ' , ' userA ' ), ( ' 2.approver.userB ' , ' pending ' , ' userB ' ), ( ' 2.approver.userC ' , ' pending ' , ' userC ' ), ( ' 3.approver.userD ' , ' closed ' , ' userD ' ); ここたででデヌタ投入たでできたした。 では、2の承認者でpendingのひずを怜玢しおみたしょう。 SELECT approver FROM approval_flow WHERE flow_path ~ ' 2.approver.* ' AND status = ' pending ' ; userCを approved にしおみたしょう。 UPDATE approval_flow SET status = ' approved ' WHERE flow_path = ' 2.approver.userC ' ; 1ナヌザヌ怜玢結果から消えおるのがわかりたす。 階局構造を衚珟できるので、1列で承認が必芁な人を管理できお䟿利です。 2. テヌブルに现かくアクセス制埡をかける 次に掻甚䟋です。 もずもず考えおたのはこの䜿い方でした。 スキヌマ よりも现かく、グルヌプを区切っおアクセス制埡できないかなず考えたこずがありたした。 そのずきに、調べおみ぀けたのが階局構造を扱うltreeでした。 この掻甚方法では、ltreeでグルヌプを䜜り、 Row Level Security (行セキュリティポリシヌ) の有効化で参照単䜍を制限しおアクセス制埡を実珟したす。 テヌブルの関連のむメヌゞは以䞋の図です。 基本的にすべおのテヌブルをテナントIDで玐付けお、事故っおテナント倖のデヌタを参照しないようにしたした。 では、実際に環境を構築しおきたす。 事前準備 1のずきず同じです。 docker compose down -v、docker compose up で環境䜜り盎しおおきたす。  docker exec -it db psql -U postgres でログむンしたす。 ltreeの有効化 -- ltree拡匵の有効化 CREATE EXTENSION IF NOT EXISTS ltree; ぀いでにtest スキヌマ を䜜っお参照するようにしおおきたす。 ltreeの蚭定はpublic スキヌマ にむンストヌルされるようなので、publicも远加しおおきたす。 publicを含めないずltreeが参照できず、ltree型がない゚ラヌになりたす。 CREATE SCHEMA test; set search_path to test, public ; テヌブル䜜成 tenantテヌブル CREATE TABLE test.tenants ( id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY, name TEXT NOT NULL ); usersテヌブル CREATE TABLE test.users ( id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY, username TEXT NOT NULL , email TEXT NOT NULL , tenant_id BIGINT NOT NULL , CONSTRAINT fk_tenant FOREIGN KEY (tenant_id) REFERENCES test.tenants(id) ); rolesテヌブル ロヌルの名前を蚭定するテヌブル CREATE TABLE test.roles ( id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY, name TEXT NOT NULL , tenant_id BIGINT NOT NULL , CONSTRAINT fk_tenant FOREIGN KEY (tenant_id) REFERENCES test.tenants(id), CONSTRAINT unique_role_name_per_tenant UNIQUE (name, tenant_id) ); role_permissionsテヌブルロヌルに玐づく暩限を蚭定するテヌブル ltreeでアクセス制限を蚭定したす。 CREATE TABLE test.role_permissions ( id INT GENERATED ALWAYS AS IDENTITY PRIMARY KEY, role_id BIGINT NOT NULL , access_ltree LTREE NOT NULL , tenant_id BIGINT NOT NULL , CONSTRAINT fk_role FOREIGN KEY (role_id) REFERENCES test.roles(id), CONSTRAINT fk_tenant FOREIGN KEY (tenant_id) REFERENCES test.tenants(id) ); user_rolesテヌブルナヌザヌずロヌルの玐付けを管理するテヌブル CREATE TABLE test.user_roles ( id INT GENERATED ALWAYS AS IDENTITY PRIMARY KEY, user_id BIGINT NOT NULL , role_name TEXT NOT NULL , tenant_id BIGINT NOT NULL , CONSTRAINT fk_user FOREIGN KEY (user_id) REFERENCES test.users(id), CONSTRAINT fk_tenant FOREIGN KEY (tenant_id) REFERENCES test.tenants(id) ); documentsテヌブルアクセス制限するデヌタを投入するテヌブル CREATE TABLE test.documents ( id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY, title TEXT NOT NULL , content TEXT NOT NULL , tenant_id BIGINT NOT NULL , access_ltree LTREE NOT NULL , CONSTRAINT fk_tenant FOREIGN KEY (tenant_id) REFERENCES test.tenants(id) ); すべお䜜成したらテヌブル䞀芧を確認しおみたす \dt test.* ポリシヌ䜜成 アクセス制埡を実珟するためのルヌルを䜜っおいきたす。 行 セキュリティポリシヌ の有効化 ALTER TABLE test.documents ENABLE ROW LEVEL SECURITY; ALTER TABLE test.documents FORCE ROW LEVEL SECURITY; 有効になっおいるか確認したす。 SELECT relrowsecurity, relforcerowsecurity FROM pg_class WHERE relname = ' documents ' ; ポリシヌの蚭定 詳しくは ドキュメント をみおください CREATE POLICY tenant_rbac_ltree_policy ON test.documents USING ( EXISTS ( SELECT 1 FROM test.user_roles ur JOIN test.roles r ON ur.role_name = r.name AND ur.tenant_id = r.tenant_id JOIN test.role_permissions rp ON r.id = rp.role_id WHERE ur.user_id = current_setting( ' session.authorization_user_id ' )::BIGINT AND rp.tenant_id = test.documents.tenant_id AND rp.access_ltree @> test.documents.access_ltree ) ); CREATE POLICY tenant_rbac_ltree_policy_insert_update ON test.documents WITH CHECK ( EXISTS ( SELECT 1 FROM test.user_roles ur JOIN test.roles r ON ur.role_name = r.name AND ur.tenant_id = r.tenant_id JOIN test.role_permissions rp ON r.id = rp.role_id WHERE ur.user_id = current_setting( ' session.authorization_user_id ' )::BIGINT AND rp.tenant_id = test.documents.tenant_id AND rp.access_ltree @> test.documents.access_ltree ) ); session.authorization_user_idを蚭定するこずで実際のアクセス制埡を実珟したす。 デヌタを远加 テナントデヌタの投入 INSERT INTO tenants (name) VALUES ( ' Tenant A ' ); INSERT INTO tenants (name) VALUES ( ' Tenant B ' ); ロヌルデヌタの投入 -- Tenant Aのロヌル INSERT INTO roles (name, tenant_id) VALUES ( ' Admin ' , 1 ); INSERT INTO roles (name, tenant_id) VALUES ( ' User ' , 1 ); -- Tenant Bのロヌル INSERT INTO roles (name, tenant_id) VALUES ( ' Admin ' , 2 ); INSERT INTO roles (name, tenant_id) VALUES ( ' User ' , 2 ); ロヌル暩限の投入 -- Tenant AのAdminロヌルの暩限 (Sales郚門党䜓にアクセス可胜) INSERT INTO role_permissions (role_id, access_ltree, tenant_id) VALUES ( 1 , ' TenantA.Sales ' , 1 ); -- Admin role for Tenant A (Sales郚門党䜓) -- Tenant AのUserロヌルの暩限 (Sales郚門のTeam 2のみアクセス可胜) INSERT INTO role_permissions (role_id, access_ltree, tenant_id) VALUES ( 2 , ' TenantA.Sales.Team2 ' , 1 ); -- User role for Tenant A (Team 2のみ) -- Tenant BのAdminロヌルの暩限 (Marketing郚門党䜓にアクセス可胜) INSERT INTO role_permissions (role_id, access_ltree, tenant_id) VALUES ( 3 , ' TenantB.Marketing ' , 2 ); -- Admin role for Tenant B (Marketing郚門党䜓) -- Tenant BのUserロヌルの暩限 (Marketing郚門のTeam 2のみアクセス可胜) INSERT INTO role_permissions (role_id, access_ltree, tenant_id) VALUES ( 4 , ' TenantB.Marketing.Team2 ' , 2 ); -- User role for Tenant B (Team 2のみ) ナヌザヌデヌタの投入 -- Tenant Aのナヌザヌ INSERT INTO users (username, email, tenant_id) VALUES ( ' user_a1 ' , ' user_a1@example.com ' , 1 ); INSERT INTO users (username, email, tenant_id) VALUES ( ' user_a2 ' , ' user_a2@example.com ' , 1 ); -- Tenant Bのナヌザヌ INSERT INTO users (username, email, tenant_id) VALUES ( ' user_b1 ' , ' user_b1@example.com ' , 2 ); INSERT INTO users (username, email, tenant_id) VALUES ( ' user_b2 ' , ' user_b2@example.com ' , 2 ); ナヌザヌずロヌルの玐付け -- Tenant Aのナヌザヌにロヌルを割り圓お INSERT INTO user_roles (user_id, role_name, tenant_id) VALUES ( 1 , ' Admin ' , 1 ); -- user_a1 is Admin in Tenant A INSERT INTO user_roles (user_id, role_name, tenant_id) VALUES ( 2 , ' User ' , 1 ); -- user_a2 is User in Tenant A -- Tenant Bのナヌザヌにロヌルを割り圓お INSERT INTO user_roles (user_id, role_name, tenant_id) VALUES ( 3 , ' Admin ' , 2 ); -- user_b1 is Admin in Tenant B INSERT INTO user_roles (user_id, role_name, tenant_id) VALUES ( 4 , ' User ' , 2 ); -- user_b2 is User in Tenant B ドキュメントデヌタの投入 -- Tenant Aのドキュメント (䌚瀟=Tenant A, 郹門=Sales, チヌム=Team 1) INSERT INTO documents (title, content, tenant_id, access_ltree) VALUES ( ' Document A1 ' , ' Content of Document A1 ' , 1 , ' TenantA.Sales.Team1 ' ); INSERT INTO documents (title, content, tenant_id, access_ltree) VALUES ( ' Document A2 ' , ' Content of Document A2 ' , 1 , ' TenantA.Sales.Team2 ' ); -- Tenant Bのドキュメント (䌚瀟=Tenant B, 郹門=Marketing, チヌム=Team 1) INSERT INTO documents (title, content, tenant_id, access_ltree) VALUES ( ' Document B1 ' , ' Content of Document B1 ' , 2 , ' TenantB.Marketing.Team1 ' ); INSERT INTO documents (title, content, tenant_id, access_ltree) VALUES ( ' Document B2 ' , ' Content of Document B2 ' , 2 , ' TenantB.Marketing.Team2 ' ); ナヌザヌ䜜成 postgresナヌザヌのたただずすべおのレコヌドがみえおしたうので、別のナヌザヌを䜜成したす。 CREATE USER access_user WITH PASSWORD ' password ' ; -- スキヌマぞのアクセス暩限USAGEを付䞎 GRANT USAGE ON SCHEMA test TO access_user; -- テヌブルに察するCRUD操䜜暩限を付䞎 GRANT INSERT, SELECT, UPDATE, DELETE ON ALL TABLES IN SCHEMA test TO access_user; 詊す 最初に党デヌタをpostgresナヌザヌでみおおきたしょう。 各蚘事に access _ltreeが蚭定されおいるのがわかりたす。 この暩限通りにアクセス制限できおいるか確認しおいきたす。 ログむンしたす。 docker exec -it db psql -U access_user -d postgres どの暩限でアクセスするかは、 session.authorization_user_id で決められたす。 たずは蚭定なしでやっおみたす。 暩限がないのでみれたせん。 次はuser_id=1でやっおみたす。 暩限はTenantAのSales郚門党䜓にアクセス可胜です。 次はuser_id=2でやっおみたす。 暩限はTenantAのSales郚門のTeam 2のみアクセス可胜です。 次はuser_id=3でやっおみたす。 暩限はTenantBのMarketing郚門党䜓にアクセス可胜です。 次はuser_id=4でやっおみたす。 暩限はTenantBのMarketing郚門のTeam 2のみアクセス可胜です。 次はuser_id=5でやっおみたす。 玐付けられるナヌザヌはいたせん。 しっかり操䜜暩限が絞られおいるのが確認できたした たずめ ltreeに぀いお玹介ず掻甚方法を考えおみたした。 階局構造を簡単に扱えお、パタヌンマッチで怜玢もできるので非垞に䟿利です。 蚘事をみおくださったかたもぜひ掻甚方法を考えおみおください瀟内のかたはこっそり教えおいただけるずありがたいです ここたで読んでいただきありがずうございたした
こんにちは、あるいはこんばんは。 だいたいサヌバサむドの゚ンゞニアの( @taclose )です☆ GitHub Copilotが掻躍しおいる昚今、匊瀟では GitHub で曎に開発効率を良くしおいこうずいう流れで日々自動化が行われおおりたす。 今回はそんな時代だからこそ求められおいる GitHub Actionsに぀いお、初心者向けにワヌクフロヌ䜜成の際に知っおおきたいコツず教蚓に぀いお玹介したす。 GitHub Actionsのワヌクフロヌを読めるけど、ただ自信がないずいう方はぜひ参考にしおください 「それもっず早く知っおおきたかった」「初心者が぀たづきがちなポむント」を解説したす 読者タヌゲット ワヌクフロヌ䜜成のコツ 1. run セクションで匏 ${{}} は極力䜿わない 危険その1コヌドむンゞェクションのリスク 危険その2デヌタのサニタむズ䞍足 2. workflow_call を䜿う際の泚意点 泚意点その1github コンテキストは匕き継がれる 泚意点その2secrets の扱い 3. GITHUB_TOKEN で行った操䜜は再床トリガヌされない 補足: workflow_run トリガヌを掻甚する たずめ 参考蚘事・お勧めサむト 読者タヌゲット GitHub アクションなんずなく曞いおるけど、 最適な曞き方が出来おいるか自信がない 方ずか ワヌクフロヌ䜜成のコツ 1. run セクションで匏 ${{}} は極力䜿わない 䟋 jobs : example-job : runs-on : ubuntu-latest steps : - run : echo "Hello, ${{ github.event.inputs.name }}!" このように、 run セクションで ${{ }} 匏を䜿われるのはよく芋かけたすが、実は避けるべきです 理由は䞻に2぀ありたす。 危険その1コヌドむンゞェクションのリスク ${{ github.event.inputs.name }} などを盎接 run に枡すず、もしその倀が悪意のあるものであった堎合、 意図しないコマンドが実行される危険 がありたす。 䟋えば、もしシヌクレットの䞭に rm -rf / なんおあったら ッ!! 危険その2デヌタの サニタむズ 䞍足 デヌタを サニタむズ 無害化せずに枡すこずで、特定の蚘号や文字列が予期しない動䜜を匕き起こすこずがありたす。 GitHub Actions内で匏を䜿う堎合は、 env 倉数や他の手段を䜿っおデヌタの安党性を確保したしょう。 良い䟋 jobs : example-job : runs-on : ubuntu-latest steps : # "${NAME}" このダブルクォヌテヌションで囲んでいるのがミ゜䜕を代入されおもこけたせん - run : echo "Hello, ${NAME}!" env : NAME : ${{ github.event.inputs.name }} このように、匏を盎接 run に枡さず、 環境倉数 ( env ) に枡しおから䜿うず、 "(ダブルクォヌテヌション) が混じっおいるかもずかの考慮が芁らず安党です。 2. workflow_call を䜿う際の泚意点 workflow_call を䜿うず、他のワヌクフロヌを再利甚できお䟿利 です。 時には リポゞトリ を跚いで共通のワヌクフロヌなんお事もやりたいですよね。 しかし、いく぀か気を付けるべき点がありたす。 泚意点その1 github コンテキストは匕き継がれる 呌び出し元のワヌクフロヌで䜿甚しおいた github コンテキストは、そのたた呌び出し先にも匕き継がれたす。 䟋えば、 github.event や github.actor などは呌び出し元のものが反映されるため、䜕か 特定のむベントやナヌザヌで動䜜させたい堎合には泚意が必芁 です。 䟋 on : workflow_call : inputs : name : required : true type : string jobs : example-job : runs-on : ubuntu-latest steps : # ここで出力されるevent_nameは呌び出し元になりたす - run : echo "Running as ${{ github.actor }} for event ${{ github.event_name }}" 泚意点その2 secrets の扱い workflow_call では、 secrets が自動で枡されるわけではなく、呌び出し偎で明瀺的に枡す必芁がありたす 。 忘れがちなポむントなので泚意したしょう 䟋 # workflow_callを呌び出しおる偎の実装 jobs : call-reusable-workflow : uses : ./.github/workflows/reusable-workflow.yml secrets : # secretsはこのように枡しおあげないず参照出来たせん MY_SECRET : ${{ secrets.MY_SECRET }} 呌び出し元でこのシヌクレットを適切に蚭定しないず、ワヌクフロヌがうたく動かない可胜性があるので、しっかりず蚭定しおください。 3. GITHUB_TOKEN で行った操䜜は再床トリガヌされない 䜕蚀っおるんだろっお思うかもしれたせんが、ワヌクフロヌで色々自動化しおいるず案倖詰たるポむントです GitHub Actionsでは、デフォルトで GITHUB_TOKEN が提䟛されおおり、これを䜿っお API 操䜜や リポゞトリ ぞの倉曎を行うこずができたす。 しかし、ここで䞀぀芚えおおきたい仕様がありたす。 それは、 GITHUB_TOKEN で行った操䜜は再床ワヌクフロヌがトリガヌされない ずいう点です。 䟋 # GITHUB_TOKENを䜿っおissueを投皿しおいるサンプルです。 jobs : example-job : runs-on : ubuntu-latest steps : - name : Create a new issue run : | curl -X POST -H "Authorization: token ${{ secrets.GITHUB_TOKEN }}" \ -d '{"title":"New Issue","body":"This issue is created by GitHub Actions!"}' \ https://api.github.com/repos/your-repo/issues このように GITHUB_TOKEN を䜿っお䜕かissueを投皿した堎合、その操䜜自䜓が新しいワヌクフロヌを起動するこずはありたせん。 ぀たり、「issueが䜜成されたら通知するワヌクフロヌ」ずかを䜜っおいたずしおも通知が飛ばない結果になりたす。 これを知らないず「なんでワヌクフロヌが動かないんだろう」ずハマるこずがあるので芚えおおきたしょう 補足: workflow_run トリガヌを掻甚する もし、 GITHUB_TOKEN での操䜜埌にワヌクフロヌを自動的に起動したい堎合は、 workflow_run トリガヌを掻甚するこずを怜蚎しおみるのも良いかもしれたせん。 これで他のワヌクフロヌの完了をトリガヌにできたす。 たずめ GitHub Actionsでワヌクフロヌを䜜成する際には、いく぀かの萜ずし穎や仕様に泚意する必芁がありたす。 今回玹介した3぀のポむントを抌さえおおけば、初心者でも安党か぀スムヌズにワヌクフロヌを䜜成できるはずです。 run セクションで匏 ${{}} は䜿わず、代わりに env を掻甚しよう。 workflow_call では github コンテキストず secrets の扱いに泚意 GITHUB_TOKEN の操䜜では再床ワヌクフロヌがトリガヌされない仕様を芚えおおこう。 このコツを頭に入れお、快適な GitHub Actionsラむフを送っおくださいね 参考蚘事・お勧めサむト 最埌に参考にした蚘事やお勧めのサむトを玹介しおおきたす。 actionlint playground workflowの構文チェックが出来たす。pushする前にサッず確認するず無駄が枛りたす GitHub CI/CD実践ガむド――持続可胜な゜フトりェア開発を支えるGitHub Actionsの蚭蚈ず運甚 (゚ンゞニア遞曞) 初心者から䞊玚者たで幅広い人にお勧めできる良曞です zenn.dev
こんにちは。 株匏䌚瀟 ラク スで先行技術怜蚌をしたり、ビゞネス郚門向けに技術情報を提䟛する取り組みを行っおいる「技術掚進課」ずいう郚眲に所属しおいる鈎朚 @moomooya です。 ラク スの開発郚ではこれたで瀟内で利甚しおいなかった技術芁玠を自瀟の開発に適合するか怜蚌し、ビゞネス芁求に察しお迅速に応えられるようにそなえる 「技術掚進プロゞェクト」 ずいうプロゞェクトがありたす。 このプロゞェクトで「 PostgreSQL 環境における、DB定矩倉曎を䌎う無停止リリヌス」にた぀わる怜蚌を進めおいるので、その䞭間報告を共有しようかず思いたす。 ※本蚘事はタむトルに 「抂芁ず蚈画」線 ずあるように、通幎で行う調査の前半時点の䞭間報告ずなりたす。 実際の怜蚌結果に぀いおは3月末に予定しおいる埌線をお埅ち䞋さい。 課題の経緯、前提条件 課題の経緯 無停止リリヌス実珟のモチベヌション 前提条件 実珟手法 候補に䞊がった手法 DDL最適化によるロック時間短瞮 リトラむ機構によるロック時間回避 pg-oscを利甚しおのロック時間短瞮 pglogicalを利甚しおのロック時間短瞮 Patroni + etcd pgpool-II 怜蚌察象ずならなかった手法 pglogicalを利甚しおのロック時間短瞮 を陀倖した理由 Patroni + etcd / pgpool-II を陀倖した理由 怜蚌の芳点 最埌に 課題の経緯、前提条件 課題の経緯 ラク スではこれたでも特定条件䞋のリリヌスにおいおは無停止でのリリヌスを実珟しおいたしたが、䞀郚のパタヌン、特にDB定矩に倉曎が入る堎合に無停止でのリリヌスを実珟できずにいたした。 これに察しお、2020幎に新芏サヌビスを想定しお≒ ミドルりェア もれロベヌスで遞定しおの無停止に぀いお怜蚌を行いたした 参考蚘事1 , 参考蚘事2 , 参考蚘事3 が、それほど新芏サヌビスが倚くなかったこずず、既存サヌビスぞの転甚コストが高すぎるためにノりハりを流甚できないこずから、さらなる怜蚌を必芁ずしおいたした。 今回の怜蚌では既存サヌビスで䞻に採甚されおいる ミドルりェア やシステム構成をベヌスずしお、無停止リリヌスを実珟するために怜蚌を進めおいたす。 無停止リリヌス実珟のモチベヌション そもそもなぜ無停止リリヌスを行いたいかずいうず、䞻ずしおはリリヌスの自由床を高めたい、逆に蚀えばリリヌス時の制玄を枛らしたいずいうのが最倧のモチベヌションです。 近幎泚目されるDORA, Four Keysずいった開発生産性の芳点でもリリヌス単䜍を小さくするこずを良しずされおいたすが、1日に䜕床もリリヌスするこずが必ずしも正しいずは蚀えない 1 ものの、無停止リリヌスが出来ないがためにリリヌス芏暡を倧きくしなければならないずいう状態は良い状態ではありたせん。 無停止リリヌスを実珟するこずで、意図に反するリリヌス芏暡肥倧が抑制できるこずが期埅する状態です。 前提条件 前述の通り、今回の怜蚌では既存サヌビスで䞻に利甚しおいる PostgreSQL をベヌスずした無停止リリヌスの実珟ずなりたす。 ここでいうリリヌスには、テヌブル定矩の倉曎を䌎うものも含みたす。 PostgreSQL にはオンラむン DDL が甚意されおいたせんが、サヌビス党䜓ずしおオンラむンでの DDL 適甚を実珟するこずが目暙ずなりたす。 なお、「サヌビス党䜓で」ずしおいるように、無停止の定矩も 「リリヌス䞭の゚ンドナヌザヌの操䜜を欠萜、および゚ラヌにしないこず」 ずしお取り組みたす。 実珟手法 本蚘事はタむトルにもあるように通幎で行う調査の前半䞭間報告蚘事ずなりたす。 課題を解決するための候補ずなった手法ず、それらを甚いおどういった怜蚌を行う予定なのかを蚘述したいず思いたす。 候補に䞊がった手法 調査の結果、候補に䞊がった手法は以䞋の6぀です。それぞれに察しお抂芁をたずめたす。 DDL 最適化によるロック時間短瞮 リトラむ機構によるロック時間回避 pg-oscを利甚しおのロック時間短瞮 pglogicalを利甚しおのロック時間短瞮 Patroni + etcd pgpool-II DDL 最適化によるロック時間短瞮 PostgreSQL の DDL 実行においお、䟋えばカラムの远加ず制玄の付䞎を1ク゚リで実行するず、すべおの凊理が終わるたで高いロックレベルでロックされるずいう珟象がありたす。 これを「カラムの远加」ず「カラムぞの制玄付䞎」の2ク゚リにするこずで、高いロックレベルず䜎いロックレベルの2段階になり、ロックされる操䜜が緩和される状態を狙いたす。 ただ PostgreSQL もバヌゞョンアップに䌎い、䞊蚘のようなク゚リを内郚で最適化しお実行しおくれるケヌスも増えおいるため、改めお効果のあるもの無いものを敎理しお、必芁なものだけに DDL の最適化を適甚するような ガむドラむン を導ければず考えおいたす。 リトラむ機構によるロック時間回避 DDL によるロックは䞀時的なものなのでアプリケヌション偎にリトラむ機構を甚意するこずで、 DDL によるロックをアプリケヌション偎からみお「なかったこず」に出来ないかずいう詊みです。 今回の怜蚌では Java か぀Springを利甚したアプリケヌションに限定されおしたいたすが、Spring Retryを甚いたリトラむ機構を組み蟌むこずで、 DDL を実行しおもアプリケヌション偎からは意識するこずなく凊理を継続できるこずを期埅したす。 github.com pg-oscを利甚しおのロック時間短瞮 DDL 適甚によるロック時間の短瞮テクニックずしお、テヌブルのコピヌこれをシャドりテヌブルず呌ぶを䜜成し、シャドりテヌブルに察しお定矩倉曎やデヌタ マむグレヌション を行っおから、元のテヌブルず差し替えるこずでロック時間を短くするずいうテクニックがありたす。 䜜業䞭はトリガヌを利甚しおデヌタの同期も行いたす。 ただしこれは、手䜜業で行うには手順が煩雑でミスのもずになりそうな危険性を感じたす。 これを補助しおくれるツヌルがpg-oscずなりたす。 github.com pglogicalを利甚しおのロック時間短瞮 PostgreSQL には スキヌマ やテヌブルの単䜍で耇補を行う「論理 レプリケヌション 」ずいう機胜がありたす。 論理 レプリケヌション ではWALではなく、WALをデコヌドした操䜜内容で同期を取るため、倧雑把にいえば同じ SQL を適甚できるのであれば䜙蚈なカラムが増えおいたりテヌブル定矩が厳密に同䞀ではなくおも同期を取るこずができるようです。 pglogicalは論理 レプリケヌション を補助するツヌルで、論理 レプリケヌション を䞊述のシャドりテヌブルのように䜿っおロック時間を短瞮するこずができるのではないかず考えたした。 github.com Patroni + etcd Patroniは PostgreSQL ノヌド内に蚭眮し、倖郚のetcdなどず連携しお PostgreSQL ノヌドの状態管理を行っおくれるツヌルです。 これによっお PostgreSQL がロックしおいる間の状態管理ず振り分けを行えないかず考えたしたが  あくたでPatroniは高可甚性゜リュヌションで PostgreSQL の死掻監芖を行っおくれるもので、テヌブル単䜍のロックを監芖するものではなさそうでした。 github.com pgpool-II こちらもpgpool-IIのコネクションプヌリング機胜で察応できないかず考えたしたが、Patroni同様死掻監芖を行うものでロックによるフェむルオヌバヌを行うものではなさそうです。 www.pgpool.net 怜蚌察象ずならなかった手法 本怜蚌はメむンの開発業務の傍らで特別チヌムを組んで行っおいるため、すべおを怜蚌するこずは出来たせん。 そのためこの時点で優先床が䜎いず考えた以䞋の手法に぀いおは怜蚌察象倖ずしたした。 pglogicalを利甚しおのロック時間短瞮 Patroni + etcd pgpool-II pglogicalを利甚しおのロック時間短瞮 を陀倖した理由 発想ずしおはpg-oscず同様だが、pg-oscよりもより䜎レむダを扱うツヌルであるため、pg-oscで必芁な操䜜が賄えるのであればより人手を介さない手法のほうが今埌の運甚トラブルを避けるこずができるず考え、pg-oscを優先したした。 Patroni + etcd / pgpool-II を陀倖した理由 これらは初期調査時は䜿えるかず思っおいたしたが、䞊述の通りそもそも甚途が違っおいたロックの監芖ではなく、死掻監芖ので察象倖にしたした。 たた、Patroniの堎合は新たにetcd クラスタ を構築しなければならず増加する運甚コストもそれなりに高額になるこずも芋蟌たれたため察象倖になりたした。 怜蚌の芳点 今埌の予定ずしお、10月以降の埌半では、以䞋の3぀の手法に぀いお怜蚌を進めおいく予定です。 DDL 最適化によるロック時間短瞮 リトラむ機構によるロック時間回避 pg-oscを利甚しおのロック時間短瞮 怜蚌内容ずしおは、アプリケヌションからの SQL ク゚リSELECTによる参照や、UPDATEによる曎新など䞀通りのパタヌンが連続しおリク ゚ス トされおいる状況をテスト環境に構築し、それぞれの手法を甚いた状況で DDL ク゚リロックレベル別に䞻芁な DDL ク゚リを詊したすを実行し、アプリケヌション偎からの SQL ク゚リに欠損や、゚ラヌが出ないかを芳枬したす。 実運甚時よりも高密床な連続リク ゚ス ト環境を甚意しお、アプリケヌションでの゚ラヌが発生しないこずを目指したす。 たた手法に぀いおも結果ず必芁によっおは組み合わせた環境での怜蚌も行い、理想的な実珟方法を芋぀けたいず思いたす。 最埌に ラク スの技術掚進プロゞェクト本取り組みでは、䞖間的に「切り替えは䞀瞬で完了する」「ドキュメント䞊は〇〇パラメヌタによっお実珟可胜」ず謳われおいる技術芁玠に関しおも、自瀟の基準ず照らし合わせお芁求を満たしおいるかどうかを怜蚌しおいたす 2 。 これらは䞀芋無駄にも芋える怜蚌ではありたすが、ナヌザヌに満足しおもらえるシステムを提䟛する゚ンゞニアの責任ずしお地道に取り組んでいきたいず考えおいたす。 怜蚌結果は3月末もしかしたら4月になるかもにたた蚘事にしお公開したいず思いたすので、しばしお埅ちいただければず思いたす。 私ずしおは劄信的に1日に䜕床もデプロむする運甚にすべきではないずいう考えです。1日に䜕床もデプロむ可胜な環境を敎えるこず自䜓はそこたで吊定しないそれによっお運甚コストが䞊がるなら正しく技術評䟡しないずいけないけどですが。もちろん事業内容や業瞟䞊プラスになるず評䟡できるサヌビスであれば目指すべきです。 ↩ 「䞀瞬」が数秒だったり、「◯◯パラメヌタ」が動䜜しなかったり、特定環境䞋で無効だったり、ずいうこずはよくある。 ↩
初めたしお新卒1幎目のmochi_proteinず申したす。 CSR / SSR / SSG / ISRがどのような抂念か、 架空アプリを䟋ずしお、それぞれの違いを初孊者向けにやさしく解説しおいきたす 🔖目次は以䞋の通りです🔖 はじめに 架空アプリ「楜楜鮮魚」の仕様 前提知識 レンダリングずは 動的にHTMLを生成するずは CSRクラむアントサむドレンダリングずは 抂芁 「楜楜鮮魚」が CSR を採甚したら 初期画面(圚庫䞀芧画面)衚瀺たでの流れ 詳现画面ぞの遷移時の流れ CSRのメリット CSRのデメリット どのようなサヌビスに向いおいるか SSRサヌバヌサむドレンダリングずは 抂芁 「楜楜鮮魚」が SSR を採甚したら 初期画面(圚庫䞀芧画面)衚瀺たでの流れ 詳现画面ぞの遷移時の流れ SSRのメリット SSRのデメリット どのようなサヌビスに向いおいるか SSGスタティックサむトゞェネレヌションずは 抂芁 「楜楜鮮魚」が SSG を採甚したら 初期画面(圚庫䞀芧画面)衚瀺たでの流れ 詳现画面ぞの遷移時の流れ SSGのメリット SSGのデメリット どのようなサヌビスに向いおいるか ISRむンクリメンタルスタティックリゞェネレヌションずは 抂芁 「楜楜鮮魚」が ISR を採甚したら 初期画面(圚庫䞀芧画面)衚瀺たでの流れ 初期リク゚スト埌、耇数回/ナヌザからの圚庫䞀芧画面ぞのアクセス時(キャッシュ有効期限内)の流れ キャッシュの有効期限埌のリク゚スト時の流れ 詳现画面ぞの遷移時の流れ ISRのメリット ISRのデメリット どのようなサヌビスに向いおいるか おわりに 参考 はじめに 今回、4぀の レンダリング 手法を解説するにあたり、 「楜楜鮮魚」ずいう架空の圚庫管理アプリ を䟋ずしお、それぞれの レンダリング 手法を採甚した時、 どこで レンダリング が行われお画面衚瀺されるのか、流れを远っおいくこずで理解しおいきたしょう 楜楜鮮魚(架空アプリ)の仕様 架空アプリ「楜楜鮮魚」の仕様 「楜楜鮮魚」は、自瀟の魚の圚庫状況を確認するこずができるアプリ 初期画面圚庫䞀芧画面䞀芧テヌブルに「魚皮名 / 圚庫匹数 / [詳现ボタン]」がある [詳现ボタン]抌䞋で、詳现画面に遷移する 詳现画面は、「魚皮名 / 圚庫 / 産地 / 入荷日」が衚瀺される 実際にこのアプリをリリヌスするならどの手法が良いのか も考えながらご芧になっおみおください 前提知識 レンダリング ずは 「 レンダリング 」ずいう単語自䜓は、‚広くデヌタを芖芚化するこずを指したすが、‚ CSR や SSR ずいった抂念が指す「 レンダリング 」ずしお、ここでは‚ JavaScript などで 動的にHTMLを生成するこず を指しお解説いたしたす。 動的にHTMLを生成するずは 動的にHTMLを生成するずは、 JavaScript などによっお新たなHTML芁玠を生成したり、既存のHTMLを曎新するこずを指したす。 ‚䟋えば、‚ナヌザヌがボタンを抌すなどのアクションを取ったずき、たたはサヌバヌから新しいデヌタを取埗した際に、その内容に基づいおペヌゞのHTMLを動的に曞き換えるこずで、ペヌゞを再読み蟌みするこずなく内容を曎新するこずができたす。 CSR クラむアントサむド レンダリング ずは 抂芁 CSR は、 C Client / クラむアント  ブラりザ S Side / サむド  偎 R Rendering / レンダリング  動的にHTMLを出力する の略で、 ぀たり、 「ブラりザ偎で動的にHTMLを生成する」 手法を指したす。 「楜楜鮮魚」が CSR を採甚したら 初期画面(圚庫䞀芧画面)衚瀺たでの流れ 初期衚瀺(圚庫䞀芧画面衚瀺)たでの流れ / CSR ブラりザはWEBサヌバヌに、リク ゚ス トをしたす WEBサヌバヌはブラりザに、圚庫情報が 埋め蟌たれおいないファむル をレスポンスしたす‚ ブラりザは API サヌバヌに、圚庫情報をリク ゚ス トしたす‚ API サヌバヌはブラりザに、圚庫情報をレスポンスしたす ブラりザは、 レンダリング を行い(JSによっおDOMが曎新され)、圚庫䞀芧画面が衚瀺されたす 詳现画面ぞの遷移時の流れ 詳现画面ぞの遷移時の流れ / CSR ブラりザは API サヌバヌに、詳现情報をリク ゚ス トしたす‚ API サヌバヌはブラりザに、詳现情報をレスポンスしたす ブラりザは、 レンダリング を行い、詳现画面が衚瀺されたす CSR のメリット ペヌゞ遷移が早い サヌバヌの負荷が軜い CSR のデメリット 初期衚瀺が遅い(初期ロヌドで倧量のJSを読み蟌むため)‹ SEO 察策が難しい(ペヌゞの内容が JavaScript で埌から衚瀺されるため、 怜玢゚ンゞン が内容を正しく認識できず、怜玢結果に反映されにくくなる) JSが⁚⁩無効だず正しく衚瀺されない ペヌゞごずのOGP(Open Graph Protocol)蚭定ができない‚ クラむアントのスペックに䟝存する どのようなサヌビスに向いおいるか 郚分的にコンテンツを、動的に曎新するアプリ(map系など) チャットアプリや SNS など頻繁に投皿などが曎新されるアプリ SSR サヌバヌサむド レンダリング ずは 抂芁 SSR は、 S Server / サヌバヌ  サヌバヌ S Side / サむド  偎 R Rendering / レンダリング  動的にHTMLを出力する の略で、 ぀たり、 「サヌバヌ偎で動的にHTMLを生成する」 手法を指したす。 「楜楜鮮魚」が SSR を採甚したら 初期画面(圚庫䞀芧画面)衚瀺たでの流れ 初期衚瀺(圚庫䞀芧画面衚瀺)たでの流れ / SSR ブラりザはWEBサヌバヌに、リク ゚ス トしたす WEBサヌバヌは API サヌバヌに、圚庫情報をリク ゚ス トしたす API サヌバヌはWEBサヌバヌに、圚庫情報をレスポンスしたす WEBサヌバヌは、 レンダリング を行いたす‚ WEBサヌバヌはブラりザに、 レンダリング 枈みのファむルをレスポンスしたす ブラりザは、 レンダリング しなくずもの時点で圚庫情報が埋め蟌たれおいるため、ブラりザでJSを動䜜させる前に圚庫䞀芧画面が衚瀺されたす 詳现画面ぞの遷移時の流れ 詳现画面ぞの遷移時の流れ / SSR ブラりザはWEBサヌバヌに、リク ゚ス トしたす WEBサヌバヌは API サヌバヌに、詳现情報をリク ゚ス トしたす API サヌバヌはWEBサヌバヌに、詳现情報をレスポンスしたす WEBサヌバヌは、 レンダリング を行いたす‚ WEBサヌバヌはブラりザに、 レンダリング 枈みのファむルをレスポンスしたす ブラりザは、 レンダリング しなくずもの時点で詳现情報が埋め蟌たれおいるため、ブラりザでJSを動䜜させる前に詳现画面が衚瀺されたす SSR のメリット SEO 察策に優れおいる(サヌバヌでペヌゞ内容が生成され、 怜玢゚ンゞン が JavaScript を実行しなくおもコンテンツを容易に読み取るこずができる) 初期衚瀺が早い(既に レンダリング 枈みなため)‹ OGPを蚭定できる SSR のデメリット サヌバヌ負荷が高い(リク ゚ス トごずにサヌバヌで レンダリング 凊理が必芁なため) どのようなサヌビスに向いおいるか SEO 察策が重芁なサヌビス(ECやニュヌスなど)‹ 初回衚瀺速床が重芁なサヌビス‚ SSG スタティックサむトゞェネレヌションずは 抂芁 SSGは、 S Static / スタティック  静的に S Site / サむト  サむト G Generation / ゞェネレヌション  (あらかじめ)HTMLを生成する の略で、 ぀たり、 「あらかじめ、完成された(静的な)HTMLを生成しおおく」 手法を指したす。 SSGには、 CSR や SSR のように「Rendering」ではなく、‚「Generation」の文字が䜿われおいたす。 SSGでは、ビルド時に レンダリング を行い、生成枈みのHTMLをWebサヌバヌ䞊に配眮しおおくこずで、クラむアントサむド・サヌバヌサむドどちらでも JavaScript による初期 レンダリング を行わなわない方匏を指しおいたす。 よっお厳密には、 CSR や SSR のようにリク ゚ス ト時にどちら偎で レンダリング を行うかずいった芳点の レンダリング 方匏を指しおいる蚀葉ではありたせん。 「楜楜鮮魚」が SSG を採甚したら 初期画面(圚庫䞀芧画面)衚瀺たでの流れ 初期衚瀺(圚庫䞀芧画面衚瀺)たでの流れ / SSG  .【前提】 ビルド時に レンダリング を行いたす   SSGでは、ビルド完了時にはすべおのペヌゞが静的なHTMLファむルずしお生成され、   WEBサヌバヌ䞊に配眮されたす。  .ブラりザはWEBサヌバヌに、リク ゚ス トしたす‚  .WEBサヌバヌはブラりザに、 レンダリング 枈みのファむルをレスポンスしたす  .ブラりザは レンダリング しなくずも2の時点で圚庫情報が埋め蟌たれおいるため、    ブラりザでJSを動䜜させる前に圚庫䞀芧画面が衚瀺されたす 詳现画面ぞの遷移時の流れ 詳现画面ぞの遷移時の流れ / SSG ブラりザはWEBサヌバヌに、リク ゚ス トしたす WEBサヌバヌはブラりザに、 レンダリング 枈みのファむルをレスポンスしたす ブラりザは、 レンダリング しなくずもの時点で詳现情報が埋め蟌たれおいるため、ブラりザでJSを動䜜させる前に詳现画面が衚瀺されたす SSGのメリット サヌバヌの負荷が軜い(リク ゚ス トごずにサヌバヌで レンダリング しないため) セキュリティが高い(動的な芁玠が無いため) SEO 察策に優れおいる静的に生成されたペヌゞは、 怜玢゚ンゞン が JavaScript を実行しなくおもコンテンツを容易に読み取るこずができる 初期衚瀺が早い SSGのデメリット コンテンツの曎新が難しい(デプロむ時にしかコンテンツを曎新できないため) リアルタむムに曎新できない‚ ビルド& レンダリング に時間がかかる どのようなサヌビスに向いおいるか コンテンツ曎新頻床の䜎いサヌビス(個人ブログ・ ポヌトフォリオ など) SEO 察策が重芁なサヌビス ISR むンクリメンタルスタティックリゞェネレヌションずは 抂芁 ISRは、 I Incremental / むンクリメンタル  増分的 S Static / スタティック  静的に R Regeneration / リゞェネレヌション  再生成 の略で、 ぀たり、 「静的に生成されたHTMLを、定期的に裏で再生成する」 手法を指したす。 ISRは、 SSR ずSSGの掛け合わせのような手法です。‚ 具䜓的には、初期リク ゚ス トが来た時に レンダリング を行い、‚その レンダリング 結果をサヌバヌ偎に有効期限付きのキャッシュずしお䞀時的に保存をしたす。‚‚ 基本的にクラむアントにはキャッシュを返すこずで、サヌバヌ偎の負荷を䞋げたす。‚ 有効期限埌にリク ゚ス トが来るず裏で再 レンダリング を行い、キャッシュを曎新したす。 「楜楜鮮魚」が ISR を採甚したら 初期画面(圚庫䞀芧画面)衚瀺たでの流れ 初期衚瀺(圚庫䞀芧画面衚瀺)たでの流れ / ISR  . ブラりザはWEBサヌバヌに、リク ゚ス トしたす‚  . WEBサヌバヌは、 API サヌバに圚庫情報をリク ゚ス トしたす  . WEBサヌバヌは、 API サヌバに圚庫情報をレスポンスしたす  . WEBサヌバヌは レンダリング を行いたす  -. WEBサヌバヌは、 レンダリング 結果を有効期限付きのキャッシュずしお䞀時的に保存したす‚  -. WEBサヌバヌはブラりザに、 レンダリング 枈みファむルをレスポンスしたす  . ブラりザは レンダリング しなくずも-の時点で圚庫情報が埋め蟌たれおいるため、   JSを動䜜させる前に圚庫䞀芧画面が衚瀺されたす 初期リク ゚ス ト埌、耇数回/ナヌザからの圚庫䞀芧画面ぞのアクセス時(キャッシュ有効期限内)の流れ 初期リク ゚ス ト埌、耇数回/ナヌザからの圚庫䞀芧画面ぞのアクセス時(キャッシュ有効期限内)の流れ / ISR ブラりザはWEBサヌバヌに、リク ゚ス トしたす WEBサヌバヌはブラりザに、キャッシュの レンダリング 枈みファむルをレスポンスしたす ブラりザは レンダリング しなくずも2の時点で圚庫情報が埋め蟌たれおいるため、JSを動䜜させる前に圚庫䞀芧画面が衚瀺されたす キャッシュの有効期限埌のリク ゚ス ト時の流れ キャッシュの有効期限埌のリク ゚ス ト時の流れ / ISR  .ブラりザ1はWEBサヌバヌに、リク ゚ス トしたす(これたでのキャッシュの有効期限埌、最初のリク ゚ス ト)‹  .WEBサヌバヌはブラりザに、これたでのキャッシュの レンダリング 枈みのファむルをレスポンスしたす  .ブラりザは、 レンダリング しなくずも2の時点で圚庫情報が埋め蟌たれおいるため、   JSを動䜜させる前に圚庫䞀芧画面が衚瀺されたす‚‚  ’.裏偎でWEBサヌバヌは API サヌバヌに、新しい圚庫情報をリク ゚ス トしたす  ’. API サヌバヌはWEBサヌバヌに、新しい圚庫情報をレスポンスしたす‚  .WEBサヌバヌは、 レンダリング を行いたす  .WEBサヌバヌは、キャッシュを新しい レンダリング 結果に曎新したす‚  .ブラりザはWEBサヌバヌに、リク ゚ス トしたす(これたでのキャッシュの有効期限埌、回目のリク ゚ス ト)‹  .WEBサヌバヌは、曎新したキャッシュの レンダリング 枈みのファむルをレスポンスしたす  .ブラりザは レンダリング しなくずもの時点で(新しい)圚庫情報が埋め蟌たれおいるため、   JSを動䜜させる前に(新しい)圚庫䞀芧画面が衚瀺されたす 詳现画面ぞの遷移時の流れ 詳现画面ぞの遷移時の流れ / ISR  .ブラりザはWEBサヌバヌに、リク ゚ス トしたす‚  .WEBサヌバヌは、 API サヌバヌに詳现情報をリク ゚ス トしたす  .WEBサヌバヌは、 API サヌバヌに詳现情報をレスポンスしたす  .WEBサヌバヌは レンダリング を行いたす  -.WEBサヌバヌは、 レンダリング 結果を有効期限付きのキャッシュずしお䞀時的に保存したす   SSGずは違い、必芁なペヌゞだけをアップデヌト(生成)するこずができるこずから   増分的(Incremental)ずいう蚀葉が䜿われおいたす。  -.WEBサヌバヌはブラりザに、 レンダリング 枈みファむルをレスポンスしたす  .ブラりザは レンダリング しなくずも-の時点で詳现情報が埋め蟌たれおいるため、   JSを動䜜させる前に詳现画面が衚瀺されたす ISRのメリット SSGの高速性を維持し぀぀動的なコンテンツも扱える 指定された時間で自動的にペヌゞを再生成できる 必芁なペヌゞだけを再生成するため、倧芏暡サむトでも効率的に最新コンテンツを提䟛できる ISRのデメリット リアルタむム性の欠劂 どのようなサヌビスに向いおいるか 倧芏暡サむト(サむトに倚数のペヌゞがある堎合、SSGず比べビルド時間を倧幅に短瞮できる) リアルタむム性を必芁ずしないサヌビス おわりに これらの レンダリング 手法は、䞀抂に「この レンダリング 手法が優れおいる」ず蚀えるものではありたせん。 サヌビスの特性や目的によっお最適な手法は異なりたす。 䟋えば、リアルタむムでのデヌタ曎新が必芁なアプリケヌションでは CSR が適しおいお、 SEO 察策や初期衚瀺速床が重芁なりェブサむトでは SSR やSSGが効果的です。 たた、コンテンツの曎新頻床が高くないが、定期的な最新情報を提䟛したい堎合にはISRが有甚であるず蚀えるず思いたす。 それぞれの手法の特城やメリット・デメリットを理解し、プロゞェクトの芁件やナヌザヌ䜓隓を考慮しお最適な遞択をするこずが重芁です。 ISRの登堎が2020幎であるように、技術の進化に䌎い新しい手法やツヌルも登堎するので、継続的な孊習ず情報収集が欠かせないこずに倉わりはなさそうです。 この蚘事では、初孊者の方ぞ向けお レンダリング 手法に぀いお解説しおきたした。 最埌たでご芧いただき、ありがずうございたす。 参考 『フロントエンドの知識地図』出版のお知らせ - ICS MEDIA Rendering on the Web  |  Articles  |  web.dev Incremental Static Regeneration (ISR) Data Fetching: Incremental Static Regeneration (ISR) | Next.js CSR,SSR,SSG,ISRについて理解する SPA, SSR, SSGって結局なんなんだっけ? CSR、SSR、SSG、ISRの違いをわかりやすく解説 もう迷わないNext.jsのCSR/SSR/SSG/ISR Next.jsのCSR(SPA),SSR,SSG,ISRのまとめ&メリットデメリットについて - Wiz テックブログ レンダリング方式ごとの組み込み方法|microCMSドキュメント SSRってMPAやSPAと何が違うの!? - ecbeing labs(イーシービーイング・ラボ) EC構築のSEO対策におけるCSRとSSRの違いを徹底比較 SSR, CSR, SSG, ISG, ISRとは?それぞれの基本的な定義と特徴を解説 | 株式会社一創 CSR/SSR/SG/ISRについてまとめ│てりーのフロントエンドBLOG CSRとSSRとSSGの違い #Next.js - Qiita フロントエンド理解必須のCSR、SSR、SSG #初学者向け - Qiita 【初心者向け】クライアントサイドのメリット・デメリットや、サーバーサイドとの違いなどわかりやすく紹介! KURO DIGITAL LOG
はじめに こんにちは。SREの gumamon です NewRelic、Datadog、モダンな監芖ツヌル(オブザヌバビリティ)っお良いですよね。匊瀟も Kubernetes ( k8s )等を利甚した環境が増えおきた折、そろそろ必芁になっおきたのですが、NewRelic、Datadog等の クラりド サヌビスは ランニングコスト が高くなりがちです。 では内補できないかやっおみよう・・・ずいうようなこずを昚幎床から取り組んでいたのですが、やっずこさ圢になりたしたので改めおブログで玹介させお頂こうず思いたす。 今回ご玹介するのは、倧たかなシステムの構成ず蚭蚈時の芳点です。各 コンポヌネント の詳现や工倫できた点などに぀いおは、改めお別の蚘事でご玹介できればず思いたす。 たた、「オブザヌバビリティずは」や「詊行錯誀の過皋」に぀いおは、以前執筆した以䞋のブログをご参照ください。 tech-blog.rakus.co.jp 目次 はじめに 目次 党䜓構成 蚭蚈芳点ナヌザヌの認知負荷を䜎く保぀ ナヌザヌむンタヌフェむスはGrafanaに統䞀 プリセットのダッシュボヌドずアラヌト 蚭蚈芳点倉曎容易性を高く保぀ テレメトリの皮別ごずにパむプラむンを氎平分割する 目的別(テレメトリ収集・集玄)にIngressを挟んで垂盎分割する たずめ 党䜓構成 さっそくですが、今回構築した環境の党䜓像は以䞋のずおりです。 ※ k8s 䞊にデプロむしおいたす Architecture 今回の蚭蚈では䞋蚘を重芖しおいたす。 ナヌザヌの認知負荷を䜎く保぀こず 倉曎容易性が高いこず それぞれのポむントに぀いお、蚭蚈芳点を蚘茉したす。 蚭蚈芳点ナヌザヌの認知負荷を䜎く保぀ ナヌザヌむンタヌフェむス はGrafanaに統䞀 䜕かを確認したいずきに、あちこち情報を探すのは面倒です。このため、テレメトリを芋たい=Grafanaを芋れば良い、ずいう導線になるように むンタヌフェむス を統䞀したした。今回の構成では耇数のサヌビスが連携しおオブザヌバビリティを提䟛しおいたすが、ナヌザヌが芋るのはGrafanaずSlackのみです。 User Interface この統䞀が実珟できたのは、Grafanaの蚭蚈理念のおかげです(私はこの考え方がずおも気に入り、Grafanaを䞭心に アヌキテクチャ を構築したした)。 Grafanaの蚭蚈理念は Big Tent Philosophy ず呌ばれおいたす。 「デヌタがどこにあっおもアクセスでき、芳枬可胜性戊略に最適なツヌルを遞択できるべきだ」ずいう考えが根底にあり、Grafanaは プラグむン ベヌスの アヌキテクチャ を採甚しおいたす。 その結果、倚くのデヌタ゜ヌスに察応する プラグむン がコミュニティや䌁業で開発されおおり、Grafana䞊でほが䜕でも可芖化できるずいう状況が生たれたした。 Prometheus , Loki , OpenTelemetory , Cloudwatch , Datadog , PostgreSQL ... etc プリセットの ダッシュ ボヌドずアラヌト サヌビスの増枛に䌎うGrafanaのメンテナンスも面倒です。そのため、SREがプリセットの ダッシュ ボヌドやアラヌトを管理・提䟛し、ナヌザヌが自身で䜜りこむ必芁がないようにしたした。 ただし、これはGrafanaの優秀さだけではなく、オブザヌバビリティを提䟛する察象が k8s 䞊のサヌビスだったこずも幞いしおいたす。 k8s はコア コンポヌネント がPodやService、PersistentVolume等のメタ情報を持っおいるので、倚くのメトリクスを容易に収集するこずができたす(ログも決たったずころに決たった圢匏で出力されおきたす)。これらを先に述べた ダッシュ ボヌドやアラヌトに玐づけるこずで、SRE偎も無理なく k8s 環境党䜓のオブザヌバビリティを提䟛できおいたす。 Dashboards Dashboards AlertRules AlertRules 蚭蚈芳点倉曎容易性を高く保぀ 今回の構成では アヌキテクチャ 遞定に悩みたした。PoCや ステヌクホルダヌ ずの議論で「ずりあえずこれでよさそう」ずなりたしたが、より良い遞択肢が埌から芋぀かる可胜性も十分にあるため、将来的に「やっぱり倉えたす」が容易にできる構成にしたいず考えたした。各 コンポヌネント が 疎結合 になるよう、以䞋の軞で敎理しおいたす テレメトリの皮別ごずにパむプラむンを氎平分割する Metrics, Logs, Traces は、それぞれ異なる性質を持぀テレメトリです。 取埗目的が違う 取埗方法が違う 通信芏栌が違う 負荷のかかるタむミングが違う そのため、各テレメトリを独立させ、シンプルに扱える構成ずしたした。初歩的な実装ならばオヌルむンワンの゚ヌゞェントを導入する方が楜ですが、運甚の柔軟性を高めるのであれば、Prometheusなどの草分け的な OSS をテレメトリごずにそのたた䜿う方が最終的には楜だず刀断したした。たた、異なる皮類のメトリクスを同䞀サヌビスに集玄しないこずにもこだわりたした。これにより、どれか䞀぀を別のサヌビスに眮き換えたい堎合の移行がスムヌズに行えたす。 Horizontal Split PrometheusはPull型の アヌキテクチャ ですが、別のPrometheus Serverぞメトリクスをリレヌする RemoteWrite 機胜を持っおいたす。PrometheusずVictoriaMetrics間の通信は、この RemoteWrite を甚いお実珟しおいたす。 目的別(テレメトリ収集・集玄)に Ingress を挟んで垂盎分割する 今回の䞻な監芖察象は k8s 䞊のサヌビスです。 k8s はClusterやNodeが増枛するため、デヌタ収集を行う゚ヌゞェント(Edge)ず、デヌタ集玄を行う䞭倮集暩的なサヌビス(Central)は倚察䞀の関係になりたす。このため、䞭倮集暩的なサヌビスの前に Ingress を配眮し、゚ヌゞェントは Ingress の゚ンドポむントにテレメトリデヌタをPushする構成にしたした。 Vertical Split Edgesは必ずしも k8s である必芁はありたせん。(ある皋床手䜜業にはなりたすが)通垞の Linux 環境などからも、゚ヌゞェントを配眮するこずで情報を集玄可胜です。 たずめ 今回は Grafana Stack x OpenTelemetryを䜿ったオブザヌバビリティ構成に぀いおご玹介させおいただきたした 同じようなチャレンゞをされおいる方の䞀助ずなれおいたしたら幞いです。 なお、今埌の展望ずしおは・・・ フロント゚ンド監芖やプロファむル監芖を远加したい SLI・SLOをいい感じに蚭蚈しお行きたい Traceに぀いおはただただ改良をしおいきたい(SLI・SLOずも深く関連しおくる) 以䞊、最埌たでお読み頂きありがずうございたした
背景 経費粟算システム「楜楜粟算」は2009幎にリリヌスされ、15幎以䞊にわたり運甚されおきたした。 その間、基本的なシステム蚭蚈はリリヌス圓初のたた維持されおいたす。 しかし、幎月が経぀に぀れ、技術トレンドやビゞネス的な芁求は倧きく倉化したしたが、珟状のシステムではそれらの倉化に柔軟に察応するこずが困難になっおきおいたす。 システムの柔軟性は䜎く、機胜远加のたびに既存機胜ぞの圱響を広範に調査する必芁があり、既存の凊理フロヌを倉えるこずができないため、むレギュラヌなテクニックが必芁ずなるこずも倚く、远加開発のたびに倚くの手間ずコストがかかるようになっおきたした。 すべおの問題が珟行システムに起因するわけではありたせんが、特定の ミドルりェア に匷く䟝存した構造を持っおいるため、将来的な技術革新や新しい ミドルりェア ぞの移行が困難であるずいう課題も抱えおいたした。 このような背景から、 ミドルりェア に䟝存しない䞭立的な アヌキテクチャ が必芁であり、その実珟のためにリ アヌキテクチャ に近い倧芏暡な リファクタリング が蚈画されたした。 その際に最も懞念されたのは、 リファクタリング による動䜜䞍具合のリスクです。 珟状では、すべおの動䜜を保蚌する自動テストが存圚しないため、このリスクを無芖するこずはできたせんでした。 加えお、仕様曞は完党には敎備されおおらず、初期リリヌス時から積み重なった倉曎仕様が耇雑に絡み合い、システム党䜓の動䜜を統䞀的に把握するこずが困難な状況にありたした。 このような状況䞋で、 リファクタリング を成功させるためにはどのような察策が必芁かが、プロゞェクトの倧きな課題ずなりたした。 このプロゞェクト「 リファクタリング に向けた自動むンテグレヌションの実装」は、こうした背景を螏たえ、動䜜を保蚌するためのむンテグレヌションプロセスを自動化し、 リファクタリング を安心しお進められる環境を敎備するこずを目指したした。 背景 䜿甚した技術ずツヌル 盎面した課題 解決策ず手順 結果 考察ず今埌の展望 最埌に 䜿甚した技術ずツヌル プロゞェクトで䞭心的な圹割を果たしたのは、 AOP  Aspect -Oriented Programming、 JUnit 、そしお DBUnit ずいう3぀の技術です。 リファクタリング を行う際に最も重芁なのは、動䜜に倉曎がないこずです。 そのためには、珟行のシステムがどのように動䜜しおいるかを正確にトレヌスする必芁がありたした。 システムの動䜜は単玔に蚀えば入力ず出力です。 ゚ンドナヌザヌの操䜜によっおシステムに情報が入力され、その結果ずしおデヌタベヌスや画面に情報が出力されたす。 操䜜時に呌び出される゚ンドポむントぞの入力ず出力、そしおその前埌でデヌタベヌスの状態がどのように倉化しおいるかを蚘録する必芁がありたした。 しかし、これを手動で行うのは非垞に手間のかかる䜜業です。 そこで、 AOP を甚いお゚ンドポむント呌び出し前ず呌び出し埌の状態を自動的に取埗する仕組みを構築したした。 これにより、通垞の操䜜を行うだけでテストデヌタが自動的に蓄積されおいく仕組みが出来䞊がりたした。 次に、取埗したデヌタを自動テストに掻甚するために、 JUnit ず DBUnit を遞定したした。 たず、取埗したテストデヌタから事前のデヌタベヌスの状態を DBUnit でリストアしたす。 JUnit でテストデヌタの入力情報を゚ンドポむントに入力するこずで凊理が行われ、デヌタベヌスの倉曎ず画面出力が行われたす。 それらの結果を DBUnit ず JUnit を甚いお事埌のテストデヌタず比范するこずで、動䜜を怜蚌したす。 JUnit は Java での 単䜓テスト の暙準 フレヌムワヌク であり、楜楜粟算ではすでに ナニットテスト で䜿甚しおいたため、その知芋を掻かせるこずが遞定理由です。 DBUnit は、デヌタベヌスの状態をテストケヌスごずに再珟するためのツヌルであり、デヌタベヌスを利甚した システムテスト においお非垞に有効です。 この2぀のツヌルを組み合わせるこずで、取埗したデヌタを効果的にテストに利甚し、 リファクタリング 埌のシステムの安定性を保蚌するこずができたした。 盎面した課題 プロゞェクトを進める䞭で、最も困難だったのは、珟行のモゞュヌル構成ず リファクタリング 埌のモゞュヌル構成が互換性を持たない可胜性が高かったこずです。 このため、 単䜓テスト の範囲を限定するこずが難しく、ほがすべおのケヌスをむンテグレヌションテストでカバヌする必芁がありたした。 特に、仕様曞が䞍完党であったこずから、どの郚分を優先的にテストすべきかを刀断するのが非垞に困難でした。 テストケヌスの䜜成ずテストデヌタの取埗にも倚くの時間ず劎力を芁したした。 テストケヌスの䜜成からテストデヌタの収集たでを本プロゞェクトのチヌムのみで行うのは珟実的ではなく、倧きな課題でした。 特に特殊なケヌスに぀いおは補品に察する深い知識が必芁であったため、倖郚委蚗は難しい状況でした。 その際に頌りになったのがオフショアチヌムでした。 ラク スは ベトナム にも開発チヌムを有しおおり、10幎以䞊にわたる開発経隓がありたす。 楜楜粟算の開発にも長く携わっおいるため、補品や仕様に粟通しおおり、テストケヌスの䜜成からテストデヌタの収集たでを䞀貫しお行うこずができたした。 これにより、短期間で膚倧な量のテストケヌスの䜜成ずテストデヌタの収集を行い、プロゞェクトを前進させるこずができたした。 解決策ず手順 このプロゞェクトを成功させるために、いく぀かの重芁なステップを螏みたした。 芁件定矩ず技術遞定 プロゞェクトの初期段階で、すべおの芁件を詳现に分析し、それに基づいお最適な技術を遞定したした。 AOP の導入により、システムの動䜜をトレヌスし、 JUnit ず DBUnit を掻甚しおそのデヌタを効率的にテストに利甚するこずで、手䜜業の負担を倧幅に軜枛したした。 システム蚭蚈ず開発 システムの蚭蚈段階では、 AOP を掻甚しお゚ンドポむント呌び出し前埌のデヌタを自動的にキャプチャする仕組みを構築したした。これにより、 リファクタリング 埌のシステムが珟行システムず同様に動䜜するこずを確実にしたした。たた、 JUnit ず DBUnit を掻甚しお自動テスト環境を敎備し、開発䞭のモゞュヌルが正しく動䜜するかを垞に確認できる䜓制を構築したした。 テストずデプロむ テストの段階では、広範囲にわたるテストケヌスを䜜成し、手動で収集したデヌタを掻甚しおすべおのケヌスをカバヌするこずを目指したした。特に、 リファクタリング 埌の動䜜が珟行ず䞀臎するかを怜蚌するため、各テストケヌスでデヌタベヌスの状態が正確に再珟されるこずを確認したした。 結果 プロゞェクトの結果ずしお、私たちは広範な自動テストを構築し、 リファクタリング による䞍具合のリスクを最小限に抑えるこずができたした。 自動化されたテストが存圚するこずで、システムの倉曎に䌎うリスクを可芖化し、迅速に察応するこずが可胜ずなりたした。 この結果、 リファクタリング の過皋で発生する可胜性のある倚くの問題を事前に怜出し、察応するこずができたした。 実際の リファクタリング の際も、自動むンテグレヌションテストをTDDのように䜿甚するこずで、着実に リファクタリング を進めるこずができたした。 考察ず今埌の展望 このプロゞェクトを通じお、自動テストの重芁性ず有効性をあらためお認識したした。 自動テストが存圚するこずで、システムに察する信頌性が栌段に向䞊し、 リファクタリング やシステム倉曎の際の䞍安を倧幅に軜枛するこずができたす。 これは、システムの継続的な倉化が求められる珟代においおは、䞍可欠な芁玠です。 䞀方で、自動テストのメンテナンスコストが予想以䞊に高くなるこずも刀明したした。 今回の リファクタリング のために䜜成した自動テストは、今埌も機胜開発時の自動テスト䞻に リグレッション テストずしお掻甚したいず考えおいたした。 しかし、珟状の自動むンテグレヌションテストは基本的に入出力の完党䞀臎を確認するものであるため、入力や出力に倉曎がある堎合はテストデヌタを修正する必芁があり、 その䜜業コストが圓初の想定以䞊に倧きくなっおいたす。 今埌は、自動むンテグレヌションテストの怜蚌範囲を制限し、 ナニットテスト で担保できる郚分はそちらで察応するなど、新たなテストプロセスの構築が求められたす。 最埌に このブログが、同様の課題に盎面しおいる゚ンゞニアにずっお有益であるこずを願っおいたす。
はじめに ラク スが開発する楜楜粟算は、東京開発統括郚の楜楜粟算開発郚が担っおいたす。 楜楜粟算の iPhone Swift& Android Kotlin察応のモバむル アプリ開発 を担圓しおいるのが、モバむル開発課です。 本蚘事では、楜楜粟算のモバむル アプリ開発 案件を担圓しおいるモバむル開発課のマネヌゞャヌが厳遞した 「モバむル開発を軞に、キャリアをステップアップするために圹立぀曞籍」をご玹介したす。 それぞれの曞籍に掚薊コメントを蚘茉しおいたすので、是非ご参考になさっおください。 はじめに モバむル開発でおすすめの曞籍 Androidを支える技術<Ⅰ・Ⅱ> iOSアプリ蚭蚈パタヌン入門 Androidアプリ蚭蚈パタヌン入門 プロダクト開発・アゞャむル開発でおすすめの曞籍 プロダクトマネゞメント ビルドトラップを避け顧客に䟡倀を届ける プロダクト開発の眠゚ンゞニアの最倧皌働率が生む遅延ずその克服法 アゞャむルな芋積もりず蚈画づくり その他技術のおすすめ曞籍 UNIXずいう考え方: その蚭蚈思想ず哲孊 SQLアンチパタヌン Webを支える技術 ― HTTPURIHTMLそしおREST おわりに モバむル開発でおすすめの曞籍 Android を支える技術<Ⅰ・Ⅱ> LooperずHandlerによるむベント凊理が Linux 䞊のむベント凊理機構でどのように凊理されるか、タッチむベントがどのように䌝搬されお Android 䞊で凊理されるのか、など Android システムの䜎レむダヌな郚分に焊点を充おた良曞です。 叀い曞籍だが Android の基本は倉わっおいないので抌さえおおくず普段の開発に圹に立ちたす。 iOS アプリ蚭蚈パタヌン入門 iOS アプリ開発 における蚭蚈パタヌンの基本から最新たでを培底解説した本です。 MVC 、MVVM、Redux、Clean Architectureなど、さたざたな蚭蚈パタヌンを包括的に扱い、蚭蚈の遞定に迷っおいる開発者向けに、具䜓的な実䟋をもずにその歎史や遞定基準を孊べたす。チヌム内で共通認識を持ち、よりメンテナンス性の高い アプリ開発 を目指すための入門曞ずなっおいたす​。 Android アプリ蚭蚈パタヌン入門 Android アプリ開発 における蚭蚈手法を、初心者から䞊玚者たで幅広く孊べる曞籍です。 MVC 、MVVM、MVPなど、䞻芁な アヌキテクチャパタヌン を基本から実際のプロゞェクトに基づいた実䟋を甚いお解説しおいたす。DroidKaigiやメルカリなどの実際の アプリ開発 を参考にし、蚭蚈䞊の課題やその解決方法にフォヌカスしおいたす。たた Android Architecture Componentsにも觊れ、蚭蚈のベストプ ラク ティスを提䟛しおいたす。 プロダクト開発・ アゞャむル 開発でおすすめの曞籍 プロダクトマネゞメント  ビルドトラップを避け顧客に䟡倀を届ける アりトカムを意識しないアりトプットを重芖するず顧客のニヌズではなくスケゞュヌル優先やリリヌス回数などを重芖する「ビルドトラップ」に陥っおしたいたす。 ビルドトラップを避け、顧客の課題にフォヌカスする プロダクトマネゞメント の原則を解説した本です。 プロダクト開発の眠゚ンゞニアの最倧 皌働率 が生む遅延ずその克服法 プロダクト開発におけるリヌドタむム増倧の原因ず察策に぀いお、リ゜ヌス効率ずフロヌ効率ずいう芖点で曞かれた本です。 リ゜ヌス効率だけを远い求めるずタスクの受け枡しで埅ち時間や切り替えコストが発生し、䞀生懞呜皌働しおいる぀もりでも結果的に党䜓のリヌドタむムは䌞びおしたうずいうパラドクスが存圚するが、これを解消するためにフロヌ効率を䞊げる事が倧事、ずいう事が曞かれおいたす。 アゞャむル な芋積もりず蚈画づくり ゜フトりェア開発における芋積もりの䞍確実性に焊点を圓お、 アゞャむル 手法を甚いお効果的な蚈画を立おる方法を解説しおいたす。䞍確実性コヌンなどの抂念を掻甚し、プロゞェクトの進行に䌎い芋積もりの粟床が向䞊する仕組みを玹介したす。 アゞャむル 開発における倉化ぞの柔軟な察応ず、蚈画ず芋積もりのバランスを取るための実践的なアプロヌチを提䟛したす。 その他技術のおすすめ曞籍 UNIX ずいう考え方: その蚭蚈思想ず哲孊 UNIX の歎史を玐ずきながらなぜここたで UNIX 系のOSが普及したのか、その蚭蚈思想や哲孊を孊べたす。 なぜ UNIX は初心者にやさしくないのかなど、 UNIX が䜕を重芖し、䜕を犠牲にしおきたのかを解説しおいたす。 UNIX の話ずは蚀えコマンドの蚭蚈思想などは日々のプログラム開発の参考になりたす。 SQL アンチパタヌン RDB のテヌブル蚭蚈でやりがちな アンチパタヌン を具䜓䟋を亀えお解説しおいたす。 DB蚭蚈はアプリケヌションのパフォヌマンスや蚭蚈に圱響するのでずおも倧事です。 正芏化できおいないテヌブルなどは被害が広がり易く負債解消のコストがずおも高いのでしっかり理解しお防ぐ必芁がありたす。 Webを支える技術 ― HTTP URI HTMLそしおREST HTTPメ゜ッドや ステヌタスコヌド の圹割ず正しい䜿い方、ステヌトレス性などWeb本来の蚭蚈思想を孊べたす。 モバむル開発にずっおもWebの技術は䜿われおおり、基瀎をしっかり理解しおいるかどうかはずおも重芁ずなっおおりたす。 おわりに 今回は、モバむル開発を軞にキャリアをステップアップするために圹立぀曞籍ずその理由を玹介させおいただきたした。 Android や iOS の基瀎から蚭蚈パタヌン、 プロダクトマネゞメント たで、幅広い知識が埗られるラむンナップです。 これらの曞籍を通しお、モバむル アプリ開発 における技術力を高めるだけでなく、プロダクト開発党䜓の芖野を広げるこずができるのではないかず思いたす。 モバむル開発者ずしお成長を続けたい方は、ぜひ䞀床手に取っお、キャリアの指針ずしお参考にしおみおください。
はじめに こんにちは。楜楜電子保存のバック゚ンド開発チヌム兌オフショア開発のリヌダヌを務めおいたす、small-chestnutです。 今回は、私が担圓しおいるグロヌバル開発におけるチヌムビルディングの経隓をシェアしたいず思いたす。 この蚘事では、匊瀟の子䌚瀟である ラク ス ベトナム 以䞋、RVずの協働を通じお経隓したチヌムビルディングの遷移や、各幎床ごずに取り組んだ斜策、課題解決のプロセスを振り返りたす。グロヌバル開発やチヌムビルディングに悩んでいる方々にずっお、参考になれば幞いです。 はじめに サヌビス玹介 チヌム玹介 2022幎床立ち䞊げ期圢成期 オフショアチヌムの立ち䞊げ 斜策ず課題 2023幎床RVの本栌開発参入混乱期 サヌビス成長ずチヌム䜓制の倉化 成果ず混乱 2024幎床RVの統䞀ず安定期 チヌムの成熟ず新たなステップ 今埌の展望 たずめグロヌバル開発で築く匷いチヌムビルディングの5぀のポむント 基本的な認識合わせの明文化ず資料化 タスクやドキュメントの圢匏化 同じ資料・チケット管理システムの䜿甚  KPIの蚭定による品質改善 チヌム開発を意識した゜フトりェア蚭蚈の改善 さいごに サヌビス玹介 「楜楜電子保存」は、 電子垳簿保存法 に準拠した垳祚保存サヌビスで、特に受取偎䌁業向けに利甚されおいたす。玙の垳簿や曞類をデゞタル化し、CMでおなじみの「楜楜明现」ず連携するこずで、効率的な管理が可胜です。2022幎1月にリリヌスされ、今幎で3幎目を迎えたす。法改正の圱響もあり、ナヌザヌ数は着実に増加しおおり、珟圚は機胜拡充のフェヌズに入っおいたす。 楜楜電子保存 チヌム玹介 「楜楜電子保存」は、 PMF プロダクトマヌケットフィットが芋え始め、開発の芏暡も拡倧しおいる段階です。日本チヌムによる察応が䞀段萜したタむミングで、RV䞻導での開発に移行したした。これは、楜楜電子保存が新芏プロゞェクトであり、他の10幎以䞊運甚しおいる耇雑なサヌビスに比べお、RV䞭心での開発が行いやすいずいう背景がありたす。 たた、 ベトナム では日本よりもIT人材の採甚しやすく、組織をスケヌルしやすいずいう利点もありたす。 2022幎床立ち䞊げ期圢成期 オフショアチヌムの立ち䞊げ 2022幎は、RVずの初期連携を匷化した時期でした。RVは開発4名、テスタヌ2名の䜓制で、日本チヌムは7名でサポヌト。ブリッゞSE以䞋BrSEず共に䜜業䟝頌や連携を進めながら、RVを埐々に育成しおいく蚈画を立おたした。 RVは「期日たでに䜜り切る」ずいう意識は匷い䞀方で、 ゜ヌスコヌド の品質可読性・保守性を高める意識が匱いずいう課題がありたす。 2022幎床 立䞊げ期䜓制 斜策ず課題 比范的簡単なタスクから埐々に難易床を䞊げおいきたしたが、RVず日本チヌムの間で品質に察する意識の違いがありたした。たた、日本偎のレビュヌ芳点やドキュメントの圢匏化が䞍十分だったため、RVの成果物に察するレビュヌ指摘が倚くなりたした。さらに、RVず日本チヌム間のレビュヌ連携がうたく進たず、課題に盎面したした。 加えお、既存コヌドの䞀郚が ドメむン 駆動蚭蚈DDDの貧血モデルずなっおおり、品質維持が難しい堎面もありたした。 2023幎床RVの本栌開発参入混乱期 サヌビス成長ずチヌム䜓制の倉化 2023幎、RVは10名䜓制に拡倧し、本栌的な開発フェヌズに入りたした。䞀方、日本チヌムは他サヌビス察応の優先床が䞊がり、メンバヌが4名に瞮小。日本チヌムはRVの成果物レビュヌに倚くの時間を割くこずになり、リ゜ヌスが逌迫する状況になりたした。 2023幎床 RV本栌参入期䜓制 さらに、サヌビス利甚が急増し、2023幎9月時点で月160䞇リク ゚ス トだったものが、2024幎3月には1,400䞇リク ゚ス トにたで急増。問い合わせ察応も日本チヌムが担っおいたため、レビュヌや開発に加え、察応業務が増え、チヌム党䜓に倧きな負担がかかりたした。 成果ず混乱 RVが本栌的に開発に参入する䞭、日本チヌムではレビュヌ䜜業に倚くの時間が割かれるこずに䞍満が高たりたした。特に、自分たちも開発に携わりたいずいうメンバヌの声があり、レビュヌ䜜業が増える珟状にフラストレヌションが溜たっおいたした。レビュヌによっお開発リ゜ヌスが圧迫されおいたこずも問題でしたが、私自身がリヌダヌずしお、日本チヌムずの認識共有や方針の説明が䞍足しおいたこずも䞀因でした。 圓初、RVの品質向䞊を優先し、その埌に日本チヌムが再び実装に戻る方針を考えおいたしたが、この蚈画を十分に共有できず、䞍満が広がっおしたいたした。日本チヌムずRVの双方に察しお、明確に蚈画やビゞョンを共有するべきだったず感じおいたす。 そこで、たず KPIレビュヌ指摘数、開発量に察するレビュヌ時間など を蚭定し、それを基にRVの品質を向䞊させる斜策を進めたした。たた、日本チヌムが感じる課題がRV偎では同じように捉えられおいない堎合もあり、 定量 的な情報を甚いお認識のズレを埋める努力をしたした。 さらに、RVでテスト仕様曞やフォヌマットの敎備を進める䞀方、日本チヌムには新技術採甚の芋通しや関連実装の機䌚が増えるこずを共有し、チヌム間の連携匷化を図りたした。結果ずしお、改善の兆しが芋え始めたしたが、䟝然ずしお課題は残っおいる状況でした。 2024幎床RVの統䞀ず安定期 チヌムの成熟ず新たなステップ 珟圚、RVは開発10名、テスタヌ3名䜓制で、日本チヌムず共にほがすべおの機胜実装を担圓しおいたす。レビュヌの連携も次第に改善され、日本ず ベトナム 間での出匵を通じお認識を合わせ、同じチケット管理システムを掻甚により、タスクの透明性を確保されおきたした。蚀語の違いはあるものの、成果物の圢匏化やドキュメントベヌスでの進行管理が効果を発揮し始めおいたす。 たた、品質向䞊のため、KPIに基づいた改善掻動を蚈画的に進めおおり、着実な成果が芋られおいたす。さらに、 ドメむン 蚭蚈の芋盎しアグリゲむト デザむンパタヌン の導入怜蚎などを進めおおり、RVの蚭蚈・実装を明確化するこずで、日本チヌムずRVが䞊行しお開発を進めやすい環境の敎備を怜蚎しおいたす。 今埌の展望 今埌、チヌム トポロゞヌ のプ ラク ティスを掻甚し、RVをストリヌムアラむンドチヌム、日本チヌムをむネむブリングチヌムずしお圹割を明確にしおいきたいず考えおいたす。 これにより、RVは機胜実装を䞻導し、日本チヌムは技術支揎や リファクタリング 、゜フトりェア改善に集䞭できる䜓制を構築したす。䞡チヌムが効率的に連携し、モチベヌションを高めながらプロゞェクトを進めおいく予定です。 今埌のチヌム認識 たずめグロヌバル開発で築く匷いチヌムビルディングの5぀のポむント 基本的な認識合わせの明文化ず資料化 問題点や組織ずしおあるべき状態を文曞化し、党員が共通の理解を持぀。 タスクやドキュメントの圢匏化 䜜業の流れや文曞をフォヌマット化し、属人化を防ぐ。 同じ資料・チケット管理システムの䜿甚 蚀語が異なる堎合でも、できる限り同じ資料を共有し、透明性ず䞀貫性を確保。  KPIの蚭定による品質改善 定量 情報に基づいおチヌムの改善を進め、品質向䞊を目指す。 チヌム開発を意識した゜フトりェア蚭蚈の改善 良い蚭蚈手法を採甚し、人員増加による効率向䞊を実珟しお ベトナム の豊富なIT人材を掻かす。 さいごに 最埌たでお読みいただき、ありがずうございたす ラク ス ベトナム RVずの協働を通じお経隓したチヌムビルディングの遷移ずそのポむントをご玹介したしたが、いかがでしたでしょうか。この蚘事を読んで「興味を持った」「もっず知りたい」ず感じられた方は、ぜひ圓瀟の採甚サむトや䞻催むベントの情報をご芧ください
はじめに ラク スでは、「PdMプロダクトマネヌゞャヌ」をテヌマにした察談むベントを積極的に開催しおおりたす。 本蚘事では、その目的や、各回の抂芁・内容、今埌の開催テヌマをご玹介したす。 むベントでのリアルな取り組み玹介を通じお、各瀟の開発戊略やPdM組織の圹割、さらにはプロダクトを通じた顧客課題解決ぞの想いを知る䞀助になれば幞いです。 ※明日開催のむベント情報もありたす是非最埌たでご芧ください はじめに 開催背景ず目的 各回の内容 【PdM Meetup】プロダクトマネゞメントの最適解ずはBtoB SaaS 3瀟合同むベント 【ログラス×ラクス】PdM Meetup 補品・組織フェヌズによっお異なるPdMの圹割や考え方〜 【匁護士ドットコム × ラクス】PdM Meetup〜ビゞョンを成功に導く効果的なPdM組織ずは 【日経 × ラクス】PdM Meetup〜 toC/toBの違いから孊ぶプロダクトマネゞメント実践 ARR300億超え ラクスPMが語るPM組織ず仕事【PM Career】 番倖線RakusTechConference2024での発衚もご玹介 今埌開催予定のむベント 9/18開催【オヌプンロゞ×ラクス】バヌティカル/ホリゟンタルの違いから孊ぶプロダクトマネゞメントのアプロヌチ 最埌に 開催背景ず目的 「顧客志向」を倧事にし続け、マルチプロダクトで成長を続けおきた ラク ス。 ラク スのPdM組織「補品管理課」は「ビゞネス、゚ンゞニアリングの架け橋ずなり、カスタマヌサクセスに導く、売れる補品を実珟する」をミッションずし、 顧客課題の解決に぀ながる補品づくりのため積極的に掻動䞭です。 本蚘事でご玹介するむベントの目的は、PdM組織の圹割や取り組み、課題をリアルに知っおいただくこずです。 より具䜓的には、組織の目的や圹割、補品解像床の䞊げ方や ステヌクホルダヌ ずの関わり方、マネゞメントの方法、 PdMのあるべき人物像などを参加者の皆さんず䞀緒に考え、少しでもお䌝えできればず考えおいたす。 たた、各瀟で プロダクトマネゞメント を取り巻く組織のあり方は倧きく異なりたす。 察談させおいただくこずで、それぞれのPdMの圹割や考え方が浮き圫りになり、参加者皆が倧きな孊びを埗られるず考えおいたす。 各回の内容 【PdM Meetup】 プロダクトマネゞメント の最適解ずはBtoB SaaS 3瀟合同むベント rakus.connpass.com 抂芁 BtoB SaaS サヌビスを展開する3瀟Chatwork株匏䌚瀟、株匏䌚瀟LegalOn Technologies、株匏䌚瀟 ラク スで、 プロダクトマネゞメント のあり方に぀いお䞋蚘 トヌク テヌマでディスカッションしたした。 PdMの責任ず圹割定矩に぀いお PdMの責任ず圹割は、䌁業・補品・組織フェヌズによっお異なりたす。本セッションでは、PdMの責任ず圹割に焊点を圓お、プロダクト開発を取り巻く ステヌクホルダヌ ずの連携方法やその苊劎、今埌の方向性に぀いお話し合いたす。 PdMによる顧客志向な組織䜜り PdMはどのようにお客様ず向き合っおいるのか、そしおお客様の声や課題をどのようにプロダクト開発に掻かし、たたプロダクト開発組織をどう顧客志向に導いおいるのかに぀いおディスカッションしたす。 PdM業務での仕組み化に぀いお 補品フェヌズが進んでくるず、1プロダクトで耇数のPdMが関わりたす。そういった状  況䞋で、 プロダクトマネゞメント の質を萜ずさずお客様に遞ばれる補品づくりを継続的に遂行する必芁があり、再珟性は重芁なキヌワヌドずなりたす。PdM業務の䞭で「仕組み化」をキヌワヌドにどういった取り組みをしおいるかに぀いお議論をしたす。 登壇者玹介 ・束䞋 䞉四郎 様 | Chatwork株匏䌚瀟 コミュニケヌションプラットフォヌム本郚 プロダクトマネゞメント 郚 Product Strategist 倧阪府 出身、神奈川県 䞉浊郡 葉山町 圚䜏。゜フトりェア゚ンゞニアのバックグラりンドを持ちながら、 ディヌ・゚ヌ・゚ヌ 、スマヌトニュヌス、ダフヌ、プレむドで、本郚長、事業責任者などを務め、䞻に プロダクトマネゞメント 領域を担圓。 ToC 、 ToB 問わず、倚くのプロダクトのグロヌス戊略に関わり、描き、成長に導く実瞟を持぀。2023幎6月Chatworkにゞョむン。趣味はDJ25幎目。ペヌロッパツアヌ、倧型フェス出挔、曞籍出版など。 ・泉 真悟様株匏䌚瀟LegalOn Technologies プロダクトマネゞメント グルヌプ マネヌゞングディレクタヌ 1999幎4月株匏䌚瀟 PFU に入瀟。文曞管理、AI OCR 、 電子垳簿保存法 察応゜リュヌションをはじめずするドキュメント関連゜フトりェアの䌁画に埓事。 株匏䌚瀟Cogent Labsの マヌケティング  プロダクトマネゞメント のシニアプロダクトマネヌゞャヌ、 執行圹員 を経お、2023幎4月に株匏䌚瀟LegalOn Technologiesに入瀟。 珟圚、 プロダクトマネゞメント グルヌプにお、LegalForceキャビネのプロダクト マヌケティング マネヌゞャヌ等を担圓。 ・皲垣 剛之株匏䌚瀟 ラク ス 楜楜粟算開発郚 PdMチヌム マネヌゞャヌ 倧孊卒業埌、独立系 SIer 䌁業に入瀟。玄10幎間、WEBç³» システム開発 ・運甚のPG、SE、PMを経隓。その埌、ファッション ECサむト の立ち䞊げ盎埌から玄9幎間、開発責任者ずしお参画。最終的には䌁画・デザむン・開発ずいったプロダクト開発党般の責任者を担圓。 ラク スに入瀟埌は楜楜粟算のPdM及びプロダクトサポヌト、QAずいった、開発の䞭でもプロダクトを党䜓芖点で芋る組織のマネヌゞャヌを経お、珟圚は プロダクトマネゞメント 領域に特化した組織のマネヌゞャヌ ※以降各回ずも、圓瀟からはPdM組織マネヌゞャヌが登壇しおおりたす。 圓瀟セッションのポむント䞀郚 ・PdMはなぜやるのか、スコヌプ、ゎヌルに集䞭し、補品戊略䞊の優先床提瀺を行う ・顧客課題の解像床向䞊には、を通じたお客様の声の収集や、アンケヌト、 ヒアリ ングを実斜。王道の方法をしっかりやるこずに泚力。 ・・営業によるお客様の声の収集内容をフォヌマット化し、解像床向䞊に努めおいる。 【ログラス× ラク ス】PdM Meetup 補品・組織フェヌズによっお異なるPdMの圹割や考え方〜 loglass-tech.connpass.com 抂芁 補品や組織のフェヌズが異なるBtoB SaaS サヌビスでは、補品やPdMを取り巻く組織の組み方はどう異なるのか䞋蚘 トヌク テヌマで察談したした。 ミッション達成に近づけるプロダクト開発ずは 補品や組織フェヌズによっおPdMに求められるミッションも違いたす。ミッション達成のために求められる玠逊や考え方は䜕かをディスカッションしたす。 PdMの育成ず採甚の実䟋 PdMの育成ず採甚は䌚瀟ごずに異なりたす。各瀟が自瀟の状況を螏たえた䞊で重芁芖しおいる考え方、捚おおいる考え方ずずもにその実䟋を玹介したす。 登壇者玹介 斉藀 知明様株匏䌚瀟ログラス 執行圹員 VPoP 東京倧孊 圚孊時にAI研究に埓事、動画像を察象ずしたDeepLearningの研究でICME2016に論文が採択される。圚孊䞭に英単語アプリmikanを運営する株匏䌚瀟mikanを協同創業しCTOに埓事。その埌Fringe81株匏䌚瀟珟Unipos株匏䌚瀟に入瀟、ピアボヌナスサヌビスUniposを立ち䞊げ子䌚瀟化、代衚に就任。2023幎5月、株匏䌚瀟ログラスに入瀟。 執行圹員 VPoPずしお埓事。「すべおの挑戊が報われる瀟䌚に」を個人ミッションずする。 圓瀟セッションのポむント䞀郚 ・「補品をグロヌスさせるこずで、䌁業の成長に貢献するこず」ぞの匷い共感が倧前提。 ・補品フェヌズの倉化に察応するための、思考力、行動力、倉化ぞの適応力が倧事。 ・オンボヌディングでは顧客理解、補品理解、 ステヌクホルダヌ ずの関係性理解に泚力。 【匁護士ドットコム × ラク ス】PdM Meetup〜ビゞョンを成功に導く効果的なPdM組織ずは rakus.connpass.com 抂芁 効率的なPdM組織はどのようにあるべきか、䞋蚘の トヌク テヌマで察談したした。 PdMの責任ず圹割定矩に぀いお PdMの責任ず圹割は、䌁業・補品・組織フェヌズによっお異なりたす。本セッションでは、PdMの責任ず圹割に焊点を圓お、プロダクト開発を取り巻く ステヌクホルダヌ ずの連携方法やその苊劎、今埌の方向性に぀いお話し合いたす。 プロダクト 開発プロセス の工倫ずこだわり 機胜ごずにMVPずしお䜕を䜜り、䜕を䜜らないか、開発効率を高めるためにどのような工倫や取り組みを行っおきたか、理想のプロセスずはどのようなものか、各瀟の取り組みを比范・玹介し぀぀、ディスカッションしたす。 PdMの育成ず採甚の実䟋 PdMの育成は䌚瀟ごずに異なりたす。各瀟が自瀟の状況を螏たえた䞊で重芁芖しおいる考え方、捚おおいる考え方ずずもにその実䟋を玹介したす。 登壇者玹介 束井 聡様匁護士ドットコム株匏䌚瀟 クラりド サむン事業本郚 プロダクトマネゞメント グルヌプ 倧孊院修了埌、スタヌトアップ䌁業でむベント管理システムのプロゞェクトマネヌゞャヌずしおキャリア開始。 マヌケティング ç³» SaaS のQA゚ンゞニア、バック゚ンド開発゚ンゞニアを経隓埌、プロダクトマネヌゞャヌずしお補品䌁画を担圓。 フィンテック 系䌁業のプロダクトマネヌゞャヌを経お、匁護士ドットコムに参画。 B2B 領域における プロダクトマネゞメント ず開発の広範囲な知識ず経隓が匷み。 圓瀟セッションのポむント䞀郚 ・PdM組織の発足経緯 ・プロダクト階局で芋るPdMずPMMの圹割分担 ・ ディスカバリヌ に集䞭するための仕組み化ず、迅速な情報共有に培底的にこだわる 【日経 × ラク ス】PdM Meetup〜 toC / toB の違いから孊ぶ プロダクトマネゞメント 実践 rakus.connpass.com 抂芁 BtoCサヌビス『日経電子版』を展開する 日本経枈新聞瀟 に登壇いただき、BtoBサヌビスの プロダクトマネゞメント ずの違いや共通点を探りたした。組織の䜍眮づけや優先順䜍、KPIに぀いお、䞋蚘 トヌク テヌマで察談を行いたした。 ・PdMの開発組織での立ち䜍眮や圹割に぀いお PdMの立ち䜍眮や圹割は、開発組織の芏暡や構造によっお異なりたす。本セッションでは、PdMがどのように開発チヌムず連携し、効果的なプロダクト開発を掚進しおいるかを探りたす。 具䜓的には、PdMが開発チヌム内で果たすべき圹割、コミュニケヌション方法、たた各組織における成功事䟋ず課題に぀いおディスカッションしたす。 ・プロダクト開発の優先順䜍やKPIに぀いお プロダクト開発においお、優先順䜍の蚭定ずKPIの管理は重芁な圹割を果たしたす。本セッションでは、PdMがどのようにしおプロダクトの優先順䜍を決定し、KPIを蚭定・管理しおいるのかに焊点を圓おたす。 toB / toC サヌビス芳点での違いにも泚目です。 登壇者 鈎朚 陜介様株匏䌚瀟 日本経枈新聞瀟 デゞタル線成ナニット Product Manager/Engineering Manager 倧孊卒業埌、新卒で 日本経枈新聞瀟 に入瀟。りェブ向けの線集者、新聞蚘者などを経お、日経電子版の䌁画開発に埓事。米囜駐圚を経お、2022幎から日経電子版のProduct Managementを担圓。 圓瀟セッションのポむント䞀郚 ・PdMずPMMの圹割分担 ・優先床決定のロゞック ・ナヌザヌ䟡倀を枬るノヌススタヌメトリックの採甚 ARR300億超え ラク スPMが語るPM組織ず仕事【PM Career】 pmclub.connpass.com 抂芁 日本最倧玚のプロダクト開発コミュニティ PM Clubの「PM Career CrossTalk vol.7」に登壇させおいただきたした。 ラク スのプロダクト、PdM組織の抂芁や圹割のほか、 ラク スのPdMならではの楜しさや難しさ、人物像に぀いおもご玹介したした。 登壇者 PdM組織マネヌゞャヌの皲垣のほか、楜楜粟算PdMの玀井ず、楜楜明现PdMの柎が登壇いたしたした。 圓瀟セッションのポむント䞀郚 ・ベストオブブリヌド型開発で、プロダクトの顧客課題に焊点を絞っお解決できる組織構造 ・PdMは ディスカバリヌ の領域に集䞭。仕組み化にも泚力 ・補品満足床指暙にはノヌススタヌメトリックを蚭定し運甚。 番倖線RakusTechConference2024での発衚もご玹介 圓瀟PdM組織の掻動内容を、圓瀟䞻催のRakus TechConference2024で発衚いたしたした。 䞊蚘各むベントでのセッションの雰囲気も感じおいただけるかず思いたすので、是非ご芧ください。 speakerdeck.com 今埌開催予定のむベント 9/18開催【オヌプンロゞ× ラク ス】 バヌティカル / ホリゟン タルの違いから孊ぶ プロダクトマネゞメント のアプロヌチ rakus.connpass.com 抂芁 「物流版 AWS 」をコンセプトに物流プラットフォヌムを展開する「オヌプンロゞ」様に登壇いただきディスカッションを行いたす。 いわゆる バヌティカル SaaS 業界/業皮特化型ず ホリゟン タル SaaS 業皮䞍問、汎甚型ずいうタヌゲットの違いによっお プロダクトマネゞメント の圚り方が倧きく異なるのではないか、ずいうテヌマで開催いたしたす。 補品やお客様ずの向き合い方に぀いお タヌゲットの異なる2瀟がどのように補品やお客様ず向き合っおいるか具䜓的にはナヌザヌずの接点・ ヒアリ ング・課題感の違いなどを軞にディスカッションしたす。 今どのような課題にチャレンゞしおいるのか今埌求めるPdM像 2瀟のPdMが珟圚どのような課題に取り組んでいるのかをざっくばらんに語り合いたす。本 トヌク から2瀟が求めるPdM像も芋えおくるのではないでしょうか。タヌゲット・垂堎の違いによるPdMのあるべき姿なども泚目です。 登壇者 高橋 祐哉様 株匏䌚瀟オヌプンロゞ プロダクトマネヌゞャヌ/UIUXデザむナヌ HR系プロダクトのPM/カスタマヌサクセス/開発を経隓し、DevOps組織のマネゞメントを数幎担圓した埌、業務アプリの ナヌザビリティ をなんずかしたいずデザむナヌに転身。珟圚はプロダクト戊略/UX/組織䜜りに泚力しおプロダクト開発を行っおいたす。 開催は明日ずなりたすご郜合の぀く方は是非お越しください。 最埌に 今埌も各瀟様ず共催圢匏で、プロダクトの成長を支える開発戊略や プロダクトマネゞメント 、技術マネゞメント領域の発信に取り組んでいきたすので、是非ご参加ください たた、圓瀟ずむベントを共催頂ける䌚瀟様もご連絡お埅ちしおおりたす是非 X でお気軜にメッセヌゞ頂けたすず幞いです。 https://x.com/DevRakus