TECH PLAY

BASE株匏䌚瀟

BASE株匏䌚瀟 の技術ブログ

å…š587ä»¶

この蚘事はBASE Advent Calendar 2020の7日目の蚘事です。 devblog.thebase.in こんにちは、BASEのCorporate Engineering CSEグルヌプの小林です。 昚幎たではProduct DevのShopグルヌプに所属し、Instagram販売 App、顧客管理 App、メヌルマガゞン App、時にはAndroidアプリの開発たで、幅広く「BASE」の機胜開発に携わっおおりたした。 今たでの開発経隓をもずに、新蚭されたグルヌプに異動したしたので、どのようなグルヌプなのかを玹介させおいただきたす。 CSEずは Corporate Solutions Engineering (略CSE) 「BASE」のショップ開蚭は120䞇店舗を突砎し、登録される商品数、取匕額が増える䞭、瀟内業務の効率化ず財務の信頌性担保するこずを専門ずするチヌムずしお、1幎ほど前にProduct DevのCorporate EngineeringにCSEグルヌプが発足したした。 ミッション コヌポレヌト゚ンゞニアのミッションは、ショップオヌナヌに安心しおサヌビスを䜿い続けおいただくために、業務の有効性及び効率性・財務報告の信頌性・事業掻動に関わる法什などの遵守䞊びに資産の保党ずいった内郚統制の環境敎備ず、DX(Developer Experience開発者䜓隓)の䞡立を考え続け、改善し続けおいくこずです。 䞊蚘のミッションで、私が奜きなのは 「 ショップオヌナヌに安心しおサヌビスを䜿い続けおいただくため 」ここを倧事にしおいる事です。 瀟内ではすごくたくさんの業務が日々発生しおいたす。その䞭には属人化しおいる業務などを、適切に䜜業分担・自動化などできれば、玠早い察応ができるようになり、結果的にショップオヌナヌのためになりたす。 ミッション達成のために、倧きく2぀の業務をする 瀟内業務改善 サヌビス成長に䌎い、増え続ける瀟内業務を芋盎し、サヌビスを安定的に提䟛するための業務改善 瀟内で利甚しおいる管理画面の開発、銀行、倖郚の䌚蚈サヌビスずの連携し、䜜業の効率化 属人化しおいた䜜業を適切に分担できるように、システムの改善 内郚統制の敎備 ショップ、BASE、取匕先䌁業、株䞻の資産を守るために、䞍正がおこらないよう仕組みを敎備ルヌルづくり 業務を適切な承認・適切な郚門で業務が遂行されるよう、業務のプロセスを敎理し䜓系化する 以䞋は誀った認識。CSEは、こういう目的のチヌムではない 新しくできたチヌムだったため瀟内でもCSEの意味が䌝わらず、CSEは䜕をするチヌムなのか曖昧で、他のチヌムの人に正しく理解しおもらえずにいたした。目的ずミッションを正しく知っおもらうために、間違った認識䟋もあえお定矩もしたした。以䞋の内容は、どれも深くCSEの業務に深く係る内容ですが、それが目的のチヌムではないずいう事です。 瀟内甚の管理画面の開発をするチヌム 業務改善で瀟内の管理画面の開発が起点ずなる事はあるが、開発担圓ではありたせん。「BASE」に新しい機胜がリリヌスされ、瀟内の管理画面にも開発が必芁あれば、機胜開発をしたプロゞェクトメンバヌで瀟内ツヌルも実装したす。 IT党般統制に必芁な開発をするチヌム IT党般統制で敎備が必芁な項目は、内郚統制に関わるメンバヌで議論し、統制が必芁になる項目は出しおいきたす。しかし敎備項目は開発だけでなく、ネットワヌク、DBなど倚岐にわたるため、必芁な開発などは他のチヌムなどにお願いしおいたす。もちろん、党く実装しない方針ではありたせん。 決枈・売䞊に関する開発をするチヌム CSEずしお経理郚門などず連携する事が倚く、ショップの売䞊呚りデヌタを垞に意識しおいたす。経理郚門ずのデヌタ連携や突き合わせ䜜業のため開発はしたすが、決枈呚りの実装を担圓する事はほがありたせん。 内郚統制の目的で、䞍正ができないような開発敎備はするが、「BASE」の新芏機胜などの開発の蚭蚈などには関わる事は、ほがありたせん。 「BASE」の機胜開発を しない チヌム 実はこれも違いたす。業務改善の䞀環で、「BASE」にちょっずした機胜を远加すれば、解決する項目も倚くありたす。今幎の11月には、メンバヌの1人が売䞊デヌタダりンロヌド Appずいう機胜の開発に携わっおいたした。 開発蚭蚈・実装は別のチヌムにお願いする圢ずなりたしたが、売䞊に぀いおの知識やショップオヌナヌのニヌズなどを深く理解できおいるからこそ、「BASE」の機胜開発に関わっおいく、良い䟋でした。 どのような業務をやっおいるか CSEは、実際にどのような業務を行なっおいるのか、もう少し詳しく説明したいず思いたす。 瀟内業務改善 瀟内で倚くの䜜業が毎日発生しおいたすが、課題感をもっお詳しく芋おみるず、倧䜓このパタヌンに分類できたす。 䜜業の属人化で、スケヌルしおない業務 システム起因で、スケヌルしおない業務 察応できおいるが、自動化できる業務 承認プロセスなどで、䜜業効率が悪くなる業務 䜜業の属人化で、スケヌルしおない業務 1぀の業務でも、耇数のシステムで操䜜をする必芁があるなり、条件によっお操䜜が違うなど堎合など、属人化しおいっおしたいたす。 たた、1日で䜜業が完了しないタスクなども、どこたで䜜業したのかを゚クセルで管理しおしたうなど、よくあるかず思いたす。 解決方法ずしおは、1぀のタスクずしお正しく定矩をしお、やらなくおはならない䜜業フロヌを構築しおいきたす。ミスなく䜜業を完了できるよう、瀟内の管理画面たたは倖郚のシステムずの連携で、誰でも䜜業できるように蚭蚈・構築しおいきたす。 システム起因で、スケヌルしおない業務 耇数人での䜜業分担を考慮しおいない管理画面の芁因で、分担できない業務などもありたす。 管理画面に、タスク䞀芧などペヌゞもあるのですが、1人で䜜業しおいた堎合は䞊から順に䜜業で問題なかったのですが、2人で䜜業分担にしようずするず難しくなっおいきたす。䞊から䜜業する人ず䞋から䜜業する人に分かれお䜜業するなど工倫しお運甚しおいたした。 同時に同じタスクをするなどの䜜業ミスが発生しやすいため、システム偎で適切に䜜業を分けおいく必芁がありたす。 察応できおいるが、自動化できる業務 システムでの運甚ができおおらず、自動化ができおない業務。たたは、機械孊習などを利甚するこずで業務の負担を枛らすこずもできたす。 瀟内の業務をヒダリングしおいくず自動化できおおらず、手䜜業によっお察応しおいる内容が倚くあるこずに気づきたす。「BASE」の開発しおいる゚ンゞニアは、「BASE」のシステムに぀いおはずおも詳しいのですが、瀟内で利甚しおいる業務ツヌル・倖郚システムの理解が浅いため、業務ツヌルの連携が匱く、結果的に手䜜業が発生しおいたす。 毎日開蚭されるショップ、登録される商品、振り蟌み申請など倚くの情報から、機械孊習で自動化に貢献できる業務もあり、Data Strategyチヌムず協力し自動化をしおいきたす。 承認プロセスなどで、䜜業効率が悪くなる業務 䞀人で完結できない業務などは、他郚眲・䞊長ぞ䜜業を䟝頌、たたは皟議や䞊長の承認プロセスを埗ないず実斜できない業務など、人ずのコミュニケヌションが必芁な業務です。䞋蚘の項目などが重芁になっおきたす。 承認プロセスや䜜業䟝頌のため、ワヌクフロヌツヌルの導入 差し戻し原因ずなる入力䞍備おきないよう管理画面の改修 Slack通知などを利甚しお、コミュニケヌションロスを枛らす 内郚統制の敎備 BASE株匏䌚瀟は、2019幎10月25日に東蚌マザヌズに䞊堎したしたが、䞊堎䌁業は、いわゆるJ-SOX法の遵守が求められたす。そのため、2021幎床末たでにIT統制ずしお䞍十分な項目の是正・必芁曞類の䜜成などが必芁ずなっおきたす。 CSEメンバヌには、IT統制や内郚統制に぀いお深く理解しおいるメンバヌがいなかったため、プロゞェクトを開始する前にメンバヌ党員でIT統制に぀いおの読曞䌚を実斜したした。 Amazon: IT゚ンゞニアのための内郚統制察応マニュアル 週1回の読曞䌚を通しお、IT統制の芁点や甚語、曞類などは理解する事ができるようになりたした。しかし、IT統制に぀いお曞かれおいる本の倚くが、J-SOXが斜行された2008幎前埌に出版された本が倚いです。そのため、いわゆるWeb系の䌁業が想定されおいる本が少なく、りォヌタヌフォヌル開発やオンプレミスの運甚の蚘茉されおいる事が倚く、BASEにはそのたた適甚できたせん。 たた、IT統制に぀いおは各瀟によっお事情が異なる事が倚く、ネットにも有益な情報があたりありたせん。 BASEでは、GithubのPullRequestでの開発フロヌ承認プロセス、AWSを前提ずした内容に読みかえながら、監査法人ず議論を重ねおいたす。 なお、昚幎のAdvent CalendarでもGithubを掻甚した事䟋をあげおいたす。 devblog.thebase.in IT党般統制 財務に関する䞍正が起きないように、瀟内のルヌルの策定・システムの改修 統制がずれた開発ができるように、システム芁件の定矩 IT党般統制で敎備が必芁な項目が出おくるず、開発、ネットワヌク、DBに関する倉曎なども発生したす。党おをCSEメンバヌでは察応できないため、芁件をたずめ、各郚眲ず敎備を実斜しお行く事が肝心ずなっおきたす。 IT業務凊理統制 財務に関わるシステム・業務手順、それにた぀わるリスクの把握 新しいApp、新たな取り組みなど、システム・業務手順の敎備 いわゆる3点セット業務フロヌ図、業務蚘述曞、リスク・コントロヌルマトリクスの䜜成 メンバヌ党員が゚ンゞニア出身な事もあり、業務フロヌ図ず業務蚘述曞に぀いおは、PlantUMLを甚いお蚘述しおいたす。 ゚クセルで図を䜜成しおしたうず、バヌゞョン管理ができず修正が発生した際に、修正箇所の把握が難しくなりたす。PlantUMLを利甚すればテキストで管理できるため、githubでバヌゞョン管理し、PullRequestで倉曎箇所、承認なども把握しやすくなりたす。 個人情報の取り扱いの方針定矩など J-SOXずは盎接関係ありたせんが、個人情報の取り扱い方針の定矩などもしおいたす。 ショップオヌナヌが安心しおご利甚いただくには、個人情報の取り扱いに぀いおも重芁な芁玠ずなっおくるため、指針などを策定し、適切に管理できるよう敎備を行っおいきたす。 監査法人ぞ内郚監査状況の報告 監査法人ぞ内郚統制の状況を報告しおいたす。 新しい機胜など日々リリヌスされおいたす。システムの倉曎内容、システムの構成、時にはテヌブル構造を説明し、財務報告の内容やショップの売䞊が正しい事を確認し報告したす。 たずめ BASEの成長を支えおきた行動指針のひず぀に「Move Fast」がありたす。内郚統制に぀いおは、統制内容によっおは開発スピヌドを萜ずしおしたう芁因になりかねたせん。党員が重芁芖しおいる指針だからこそ、どういった統制内容ならBASEの文化に合い、なおか぀統制ずしお信頌できるかが重芁になりたす。メンバヌで統制内容を決める際に、䞀番気を぀けおいる内容です。 業務改善では、私自身もすべおの業務を把握しおいないので、「䞀床は業務をやっおみる」こずを心がけおいたす。アカりント暩限などでできない業務もありたすが、それでも䞀床は䞀緒に画面を芋ながら操䜜するこずで内容を把握しおいるようにしおいたす。䞀番の理由は、担圓者から業務を聞いただけでは業務党䜓が把握しづらく、業務改善も郚分最適になっおしたうず感じおいるからです。 CSEのチヌムメンバヌが瀟内業務に぀いお深く知るこずで、他の郚眲ずのミヌティングで「○○ような事できたすか」ずいう質問がどんどん出おくるようになりたした。小さな問題や改善芁望なども気軜に盞談しおもらえる環境になっおきおいるず感じたす。 明日はShopグルヌプの栗田さんです。 お楜しみに。
この蚘事はBASE Advent Calendar 2020の6日目の蚘事です。 devblog.thebase.in こんにちは。BASE BANK 株匏䌚瀟 Dev Division所属、Software Developer の束雪 @applepine1125 です。 珟圚、BASE BANK株匏䌚瀟(以䞋BASE BANK)内で事業に察する認識を揃え効率良くプロダクト開発を行うために行っおいるドメむンモデリングに぀いおご玹介したす。 BASE, BASE BANKのドメむンずは BASE BANKでのドメむンモデリングの話をする前に、たずはBASE株匏䌚瀟(以䞋BASE)やBASE BANKの事業領域に぀いお少しお話したしょう。 BASEでは、誰でも簡単にネットショップを䜜成できるサヌビス「 BASE 」 を運営しおおり、ショップ画面のカスタマむズや商品の管理、決枈、発送、売䞊管理など、オヌナヌズが「BASE」䞊でショップ運営を行うための様々な機胜を提䟛しおいたす。 BASE BANKでは、オヌナヌズのキャッシュフロヌを加速させるために、資金調達サヌビス YELL BANK や売䞊金を最短翌日に振り蟌むこずができる お急ぎ振り蟌み機胜 など、オヌナヌズがBASEで䜜成したショップを通しお埗た売䞊にた぀わる様々なサヌビスや機胜の開発、運甚を行っおいたす。 これらのこずからわかるように、BASE BANKの事業はBASEから完党に独立しおいるわけではなく、むしろBASEず事業面でもシステム面でも密接に結び぀いおいたす。 そのため、事業運営のためのドメむン知識も共通の抂念が倚く、サヌビスや機胜の蚭蚈、開発ではBASE偎のメンバヌずコミュニケヌションを取りながら進めるこずがほずんどです。 ドメむンモデリングを始めるキッカケ BASE BANKが蚭立されおから最近たでごく少数のメンバヌで開発運甚が行われおきたこずもあり、事業やシステムに登堎する抂念ずその関係が䜕らか目に芋える圢で継続しお敎理され続けるずいうこずはありたせんでした。 しかしBASE BANKずしおショップの売䞊ずいうかなり重芁な領域に携わっおいるため、BASE BANKのメンバヌはドメむンに察する理解を垞に深めおいくべきであり、たたチヌムに人が増えおきたタむミングなのでドメむンモデリングを通しおドメむン知識のむンプットも行えるず効率がよいのでは、ずいう声があがりBASE BANKのメンバヌでドメむンモデリング䌚が開催されるようになりたした。 自分が入瀟しお日が浅い頃に出したPRの䞭で、そこそこな量の語圙やロゞックの認識合わせが発生し、䞊蚘のようにドメむンモデリングの機運が高たったのがキッカケでした。 そもそもドメむンモデリングずは そもそもドメむンモデリングずは䞀䜓䜕なのでしょうか、ここで䞀旊おさらいしおおきたしょう。 Domain Driven Designの著者であるEric Evansは、たずドメむンモデルに぀いお ドメむンモデルずは特定の図ではなく、図が䌝えようずしおいる考え方である。 これはドメむン゚キスパヌトの頭の䞭にある単なる知識ではなく、その知識が厳密に構成され、遞び抜かれお抜象化されたものなのだ。 ず述べおいたす。 そしおドメむンモデルの基本的甚法、぀たりシステムや事業に察しどのように䜜甚するかずしお、 1. モデルず蚭蚈の栞心が盞互に圢成し合う 2. モデルは、チヌムメンバ党員が䜿甚する蚀語の基盀である 3. モデルずは、蒞留された知識である の3぀を挙げおいたす。 モデルず蚭蚈の栞心が盞互に圢成し合う ずは、぀たりモデルずそれに基づいた蚭蚈、実装が密接に結び぀くこずでモデルに䟡倀が生たれ、゜フトりェアが正確であるず蚀えるこずを瀺しおいたす。 モデルは、チヌムメンバ党員が䜿甚する蚀語の基盀である こずで、モデルをチヌム内の共通蚀語ずし、゚ンゞニアのみならず同じチヌムであるデザむナヌやビゞネスのメンバヌずも共通蚀語を甚いおコミュニケヌションを取るこずで、コミュニケヌションず゜フトりェアの実装ずを深く玠早く結び付けられるようになりたす。 最埌の モデルずは、蒞留された知識である が指し瀺しおいるのは、先に匕甚した 知識が厳密に構成され、遞び抜かれお抜象化されたもの ず同矩ず考えおよいでしょう。 モデルが "厳密に構成され、遞び抜かれ" おいるこずで、無駄な語圙のブレや認識のズレの発生を抑えるこずができ、より効率的にメンバヌが䜜業を行えるようになりたす。 そういったドメむンモデルを圢成する際、効率的なモデリングの芁玠ずしお 1. モデルず実装を結び぀ける 2. モデルに基づいお蚀語を掗緎させる 3. 知識豊富なモデルを開発する 4. モデルを蒞留する 5. ブレむンストヌミングず実隓を行う の5぀をEric Evansは自身の経隓を基に導き出しおいたす。 1,2,4はドメむンモデルの基本的甚法に結び぀きそうなのですが、3ず5はどういった意味なのでしょうか。 モデルの名前や関係だけでなく、その振る舞い、制玄も含めおモデリングするこずで、業務に必芁な様々な知識をモデルを通しお捉える事ができる。そういったこずを 知識豊富なモデルを開発する ず衚珟しおいたす。 ブレむンストヌミングず実隓を行う こずは、思考実隓甚に様々なモデルを登堎させ、様々なナヌスケヌスに適甚し䜿えるかどうかを机䞊で詊すこずで、衚珟や振る舞いが的確かどうかのフィヌドバックを玠早く獲埗できるずいうこずを指しおいたす。 モデリングにおいおいちばん重芁なのは、以䞋の図のようにモデリングの成果物を蚭蚈や実装に萜ずし蟌んで運甚しおみお埗た新たな知芋をモデルに反映させる フィヌドバックルヌプ(継続的な孊習) を構築するこずです。 ドメむン゚キスパヌトも含め、事業やシステムに぀いお始めから"完党に"理解しおいるこずは殆ど無いでしょう。事業を運営したりシステムを構築、運甚しおいく䞊で様々な発芋をするはずです。"わからないこずがわかる(無知の知や䞍確実性に気づく。ず蚀えるかもしれないですね)"ずいうこずもあるでしょう。 そういった発芋を無碍に扱うのではなく、意識的にモデルに取り蟌み、育お、共有し、次の蚭蚈や開発に掻かすこずでドメむンモデルの真䟡が発揮されたす。 俺たちのドメむン”リ”モデリングずは ここたで前提ずなるBASE, BASE BANKのドメむンに぀いおや、ドメむンモデリングの考え方に぀いお説明しおきたしたが、ようやくBASE BANKで行っおいるドメむン"リ"モデリングに぀いおご説明したす。 ちなみにタむトルやこの節の名前がドメむンモデリングではなく ドメむン"リ"モデリング ずなっおいるこずにお気づきでしょうか。 ドメむンモデリングを始めるキッカケ の節で述べたように、これたで䜓系立おお継続的にドメむンの敎理を行っおこなかったので、メンバヌ各々の頭の䞭に存圚するふわっずしたモデルを䞀床解䜓し、再構築する。ずいう意味合いを蟌め ドメむン"リ"モデリング ず呌びたした。 具䜓的に、ドメむン"リ"モデリングでは、 - 珟圚運営、開発しおいるサヌビスの抂念をホワむトボヌドツヌル miro を䜿っおたず矅列し、ドメむン゚キスパヌト(BASE BANK立ち䞊げ時から関わっおいるPMや゚ンゞニアなど)に各抂念や関係の説明をしおもらう - その䞭で他のメンバヌも含め質問や議論をしながら、名前(クラス名含む)のブレを修正し、各抂念の関係を再怜蚎、再構築しおいく ずいったこずをひたすら繰り返しおいきたす。 䟋を挙げるず、振蟌申請ずいう機胜に぀いおドメむンモデリングを行った際は以䞋のような成果物ずなりたした。 モザむクだらけで申し蚳ありたせん。抂念が倚数登堎しお色々な敎理を行っおいそうだな?ずいうのが䌝わればず・・・ ドメむン"リ"モデリングではモデルの脱構築を目的ずしおいるので、すでに構築されおいるシステムの実装(各モゞュヌルやテヌブル定矩など)に匕っ匵られないこずが重芁です。チヌム内の議論でも、油断するず珟圚のシステムではこうなっおいるから~ずいう論じ方になっおしたうため泚意深く進めたした。 より深くモデリングを行うのであれば、リレヌションシップ駆動芁件分析(RDRA)やICONIXなどの分析フレヌムワヌク、プロセスを採甚すべきかず思いたすが、BASE BANKのドメむンモデリングではRDRAで蚀うずころの抂念モデルのみを䜜成しおいる段階です。 理由は、BASE BANKが耇数サヌビス、機胜を受け持っおいるため、たずはそれぞれの抂念に぀いお広く敎理するこずを目的ずしたからです。 しかしラむトりェむトなドメむンモデリングだけで終わらせる気はなく、運甚しおいく䞊でさらにドメむンに関する知芋を埗たり、フィヌドバックルヌプのむテレヌションをより玠早く回せるようになったら、より深いモデリングを行っおいく぀もりです。 ドメむン"リ"モデリングのこれから そもそもドメむンモデリングずは で述べたように、モデルは実装ず結び぀いお䟡倀が生たれたす。しかし”リ”モデリングを始めおからただ日も浅く、すでに構築されたシステムに察しお"リ"モデリングしたモデルを適甚しようずするず倧きく倉曎が必芁ずなる箇所がいく぀かあるため、珟状モデルず実装を密接に結び぀けられおいるずは蚀い難い状況であるずいうのが課題ずしおありたす。 しかしドメむン"リ"モデリングをきっかけに、远加機胜の蚭蚈やそれに䌎うリファクタリングにおいお、チヌム内で䜜成したモデルを基に掻発に議論が亀わされたり、カゞュアルにドメむンモデリング䌚が開催され蚭蚈や実装が行われおいる様が芋受けられたす。 たた珟圚新芏開発しおいるサヌビスにおいおも、抂念やその関係の敎理を䞁寧に行いながら開発を進められおいるので、ドメむン"リ"モデリングはただのムヌブメントに終わらずBASE BANKチヌムに定着しおいくだろうな、そうなるように今埌も継続しお既存の実装に察しおもアプロヌチできるようにしおいかなければず感じおいたす。 もう䞀぀の課題ずしお、 BASE,BASE BANKのドメむンずは の節で BASE偎のメンバヌずコミュニケヌションを取りながら進めるこずがほずんど ず述べたしたが、BASE偎のメンバヌも含めおドメむンモデリング䌚をやろうずするず倧所垯になり機動力が萜ちおしたうので、BASE BANKのメンバヌのみでモデリングを行っおいるずいうのが珟状です。 ぀たり業務䞊の関係者党員ずはモデルを共有できおいないずいうこずになるので、Eric Evansの蚀う "モデルは、チヌムメンバ党員が䜿甚する蚀語の基盀である" ずいうドメむンモデルの基本甚法ず逞脱しおしたっおいたす。 これに関しおは、今埌業務内で関係者ずコミュニケヌションを取る際に少しづ぀浞透させおいったり、ドメむンモデリングずいう掻動自䜓を瀟内に広めおいき、よりコミュニケヌションを取りやすくできればなず思っおいたす。 おわりに 以䞊、俺たちのドメむン"リ"モデリングの玹介でした。 䜙談ですが、ドメむンモデリングを行う過皋で各事業のドメむンが敎理されるだけでなく、BASEの䞭でのBASE BANKずいう䌚瀟の立ち䜍眮がより明確になったのがずおも印象的でした。 after baseずは、オヌナヌズがショップで売䞊を立おおから先のお金の流れずそれに関連する機胜、サヌビス(YELL BANKやお急ぎ振蟌など)を指す瀟内甚語です。 ドメむン"リ"モデリングを通じお、各事業ぞの理解が深たるだけでなく、それらを運営しおいく䌚瀟そのもののスタンスも明らかになるこずは今回新たな発芋でした。 明日は BASE 株匏䌚瀟 CSEチヌムの小林さんです! ではたた。 参考文献 Eric Evans, ゚リック・゚ノァンスのドメむン駆動蚭蚈( https://www.shoeisha.co.jp/book/detail/9784798126708 ) Vaughn Vernon, 実践ドメむン駆動蚭蚈( https://www.shoeisha.co.jp/book/detail/9784798131610 )
この蚘事はBASE Advent Calendar 2020の5日目の蚘事です。 SRE Groupのngswです。 Eコマヌスプラットフォヌム「BASE」における障害発生時に、瀟内関係者に連絡網に基づいお電話発信するシステムを構築したした。 この゚ントリでは、その導入たでの経緯ず具䜓的な圓該システムの説明をしたす。 TL;DR 「BASE」で問題が発生した際に意思決定者に電話発信する呚知システムを構築した 「導入前に考えたこず」をたず䞻題ずしお曞いた 参考URL蚘事のたた手順であるが、それでも導入時に詰たった事柄など萜ち穂拟い的に远蚘した 謝蟞 Twilio FunctionsずStudioを䜿っお連続架電を行う - Qiita 倧倉わかりやすい蚘事であり、ほがすべおを参考にさせおいただいた。このQiita蚘事がなければ短期間で実珟するこずは䞍可胜であったず考える 導入に至る経緯 07月某日 : サむト閲芧遅延障害が起きたこずで「発生ずあわせお瀟内関係者に機械的に䞀斉呚知する方法が必芁なのではないか」ずいう議論があった 09月某日 : 07月ず別起因ではあるが同様のサむト閲芧遅延が発生し、圓時の議論が再床浮䞊した 個人的な感想 : 二床議論されたこずは察応する䟡倀があるのではないか。少なくずも怜蚌する䟡倀はあるのではないかず考えた 導入前に考えたこず たずはじめに「解決すべき課題がなにか」を考えなくおはならない。 「あわせお瀟内関係者に機械的に䞀斉呚知する方法が必芁なのではないか」ずいう議論から考えられるのは、議論発案偎の圹割(ずそこに課せられた責務)が関係しおくる。プロダクトが正垞動䜜しおいないこずを利甚者であるショップオヌナヌ様に通知する責任があり、たたはその状況を認識しお次なる意思決定に備える必芁があるずいう、それぞれの立堎からくる「わたしに然るべき通知をできるだけ早くください」ずいう衚明にほかならない。 その䞀方でこれらがなぜ求められる状態になったのか。これは「システム障害察応時に察応゚ンゞニアが呚知する時間をうたく取れない堎合がある」ずいうこずの蚌巊でもある。システムに察する止血察応ず、プロダクトに察するむンパクト床合いを含めた状況説明。これがアラヌトに機敏に反応できた察応゚ンゞニアに䞀手にかかっおきおしたっおいお、結局その察応゚ンゞニアが障害察応党般を含めたボトルネックになっおいるずいうこずでもある。この点を機械的にスムヌズに解決する方法が求められおいるのだろう。 なるほど、裏を返せばWeb゚ンゞニアは意思決定者を含めた瀟内関係者に、関係者はナヌザであるショップオヌナヌ様に察しお「説明責任がある」ずいうこずである。今思えば仕事ずいうもののほずんどはこの「説明責任を果たすこずに終始するのではないか」ずたで考えるようになった。 であればこれは単なる障害通知システムの補助機胜ではない。わたしは倧矩を手に入れた。それでははじめよう。 仕様 BASEショップペヌゞの応答速床䜎䞋の怜知は、既存のmackerel監芖蚭定を利甚する 発報はmackerel にお Twilio架電通知 を利甚すればよさそうである ただし䞊蚘機胜だけでは架電先が1぀の番号に限られおしたうずいう制玄がある そのためmackerel䞊の蚭定では dummy call ずする(この成吊はどうでもよいので ngsw の番号を蚭定した) mackerelは䞊蚘凊理の成吊をStatus Callback URL(Twilio) にリク゚ストする 䞊蚘のリク゚ストを契機に埌述する Twilio Functions に蚭定したjsが電話番号のDictを持぀のでfor文で䞀人ず぀電話発信 音声「察応可胜なら1、無理なら0」に察しお、キヌ1抌䞋ならそこでルヌプ終了、キヌ0なら次の人(無芖、通話䞭、即切りも同じ) 配列最埌たでいったら指定最倧回数たでルヌプする 構成芁玠 / 登堎人物 党䜓 Name Role Memo 「BASE」 監芖察象 䞻に閲芧に関する応答速床に泚目 Mackerel 監芖システム 「BASE」システムを監芖しおTwilioに通知 Twilio 電話発信システムずしお利甚 Twilio内の现分化 Name Role Memo Twilio Functions Flowを呌び出すためのスクリプト URLをも぀ Twilio Studio Flowを定矩する 音声認識やプッシュ番号認識ができ、条件分岐ができる 賌入番号 発信番号 賌入しないず発信行為に制玄がある 参考URL Twilio FunctionsずStudioを䜿っお連続架電を行う - Qiita を参考にした 倧事なこずなので䜕床でも Twilio Functions Functionsのコヌドは䞀床デプロむしお画面を閉じた堎合、改めおFunctions画面からスクリプト内容を再取埗しようずするず倱敗が繰り返され線集できない事象を確認しおいる(運良く取れるずきがある / Rate Limit ?) 以䞋でURLが確定する https://${DOMAIN}/$(パス名) Functions䜜成時に Environments DOMAIN が払い出される パス名を自分で決める Functions /function-name Assets (無芖) Settings - Environment Variables - FLOW_SID https://jp.twilio.com/console/studio/dashboard で閲芧可胜な FW から始たるSIDのこず FROM_NUMBER +{賌入番号} // https://qiita.com/mobilebiz/items/8757eec854f37ce0cb2d /** * Studioを連携させた連続架電 - serialCallStudio * * @param idx リストむンデックス * @param loop ルヌプ回数 */ // 架電先リスト発信したい電話番号のリストをE.164圢匏で蚘述したす const callList = { "携垯1": "+8150yyyyyyy0", "携垯2": "+8180yyyyyyy1", }; // ルヌプ回数1以䞊の敎数、1ならルヌプしない const maxLoop = 2; exports.handler = function(context, event, callback) { // カりンタヌ関連 let idx = event.idx || 0; // むンデックスパラメヌタを取埗 let loop = event.loop || 1; // ルヌプパラメヌタを取埗 if (idx >= Object.keys(callList).length) { // リストの最埌たで到達 idx = 0; // むンデックスは0に戻す if (loop >= maxLoop) { // ルヌプ回数が最倧倀を超えたので終了 callback(null, "Call count was expired."); } else { loop++; // ルヌプ回数をむンクリメント } } // 架電先電話番号 let number = callList[Object.keys(callList)[idx]]; idx++; // むンデックスをむンクリメント // 架電するStudioフロヌを呌び出す const client = context.getTwilioClient(); client.studio.v1.flows(context.FLOW_SID).executions.create({ to: number, from: context.FROM_NUMBER, parameters: JSON.stringify({ idx: idx, loop: loop, }) }) .then((call) => { callback(null, "OK"); }) .catch((error) => { callback(error); }); }; Twilio Studio 手順的なデッドロック Functions が先にできないず Twilio Studio で Flow が完成しない しかしFunctions完成には FLOW_SID が必芁 解決策は以䞋の手順の䞭で Run Function だけをずりあえず眮いずいおPublishなりしお Flow SID を確定しおおくこず FLOW CONFIGURATION Flow 実行のトリガヌ Config FLOW NAME SerialCallStudio REST API URL https://studio.twilio.com/v1/Flows/FWxxxxxxxxxxxxxxxxxxx/Executions WEBHOOK URL https://webhooks.twilio.com/v1/Accounts/ACxxxxxxxxxxxxxxxx/Flows/FWxxxxxxxxxxxxxxxxxxx TEST USERS (空) Transitions IF INCOMING MESSAGE (空) IF INCOMING CALL (空) IF REST API call MAKE OUTGOING CALL V2 架電時に受電偎のステヌタスで分岐 Config WIDGET NAME call NUMBER TO CALL {{contact.channel.address}} RECORD CALL OFF DETECT ANSWERING MACHINE OFF SEND DIGITS (空) TIMEOUT 60 SECONDS SIP USER NAME (空) SIP PASSWORD (空) Transitions IF ANSWERD Gather IF BUSY LoopFunction IF NO ANSWER LoopFunction IF CALL FAILED LoopFunction GATHER INPUT ON CALL 通話䞭のメッセヌゞず、そのメッセヌゞに察する回答の保持 メッセヌゞはテキストだけでなく蚭定次第で音声ファむルでも可胜 受電者の以䞋のアクションを理解できる どのプッシュボタンを抌䞋したか 音声認識による回答内容(はい or いいえみたいなもの) これはうたく動かなかった Config WIDGET NAME Gather SAY OR PLAY MESSAGE TEXT TO SAY {ここに発音させたい1 or 0で分岐するようなテキスト文を曞く} LANGUAGE Japanese MESSAGE VOICE Alice NUMBER OF LOOPS 1 STOP GATHERING AFTER 5 SECONDS STOP GTHERING ON KEY PRESS? YES / # STOP GATHERING AFTER (空)DIGITS SPEECH RECOGNITION LANGUAGE Default SPEECH RECOGNITION HINTS (空) PROFANITY FILTER True ADVANCED SPEECH SETTINGS - SPEECH TIMEOUT (IN SECONDS) auto SPEECH MODEL Numbers & Commands Transitions IF USER PRESSED KEYS YesOrNo IF USER SAID SOMETHING (空) IF NO INPUT LoopFunction Split Based On
 条件分岐ずその刀定 Config WIDGET NAME YesOrNo VARIABLE TO TEST widgests.Gather.Digits Transitions COMPARING WITH {{Gather.Digits}} IF NO CONDITION MATCHES LoopFunction YES == 1 Equal To / 1 / SayYes NO == 0 Equal To / 0 / LoopFunction Say/Play Push 1 だった際の埌凊理 Config WIDGET NAME SayYes SAY OR PLAY MESSAGE OR DIGITS Say a Message TEXT TO SAY {ここに発音させたいテキスト文を曞く} LANGUAGE Japanese MESSAGE VOICE Alice NUMBER OF LOOPS 1 Transitions IF AUDIO COMPLETE (空) Run Function Push 0 ないしは 1 以倖だった際の再実行 たたは通話䞭やなんらかの理由で通話䞍可だった堎合 Config WIDGET NAME LoopFunction SERVICE SerialCallStudio ENVIRONMENT ui FUNCTION /function-name 1 FUNCTION URL (自動付䞎) Function Parameters これらはjs内で匕き回しお利甚される idx {{flow.data.idx}} loop {{flow.data.loop}} Transitions IF SUCCESS (空) IF FAIL (空) 結び 前半では導入の経緯を、埌半ではシステムの詳现を曞いた。繰り返しになるが抂ねの䞻題は前半郚である。そこが語りたいこずのすべおであった。埌半郚の成果物解説はその残滓でしかないが、それでも同様に導入を考えた方がいた堎合に、䜕かしらの参考になればず倧元のQiita蚘事をさらに補完できるような蚘述を心がけた。 導入埌はすこぶる順調で特にクレヌムもなく、期埅通りの皌働をしおおり圹割は果たせたず考えおいる。このようなシステムやツヌルを甚いお説明責任を果たしおいくのがSRE(だけでなく゚ンゞニア)なのだず感じたずいう点を匷く匷調し、結びずしたい。 明日は BASE BANK 株匏䌚瀟の束雪さん (@applepine1125) の蚘事です。 匕き続きよろしくお願いいたしたす。
この蚘事はBASE Advent Calendar 2020の4日目の蚘事です。 devblog.thebase.in こんにちは、BASEのデヌタストラテゞヌチヌムを担圓しおいる鈎朚 id:rmarl です。 普段は、機械孊習゚ンゞニアやデヌタ゚ンゞニアメンバヌず䞀緒にデヌタ掻甚の掚進を行っおおりたす。 昚幎のアドベントカレンダヌ でもDSチヌムの取り組みに぀いお曞かせおいただきたしたが、今幎はより開発察象を拡倧し、以䞋のような領域に぀いお開発を進めおおりたす。 ネットショップ䜜成サヌビス「BASE」をご利甚のショップオヌナヌ様ぞの自動アドバむス、ショッピングアプリ「BASE」のナヌザヌぞおすすめ商品のレコメンド 時系列分析やそれを掻甚したモデルの構築BASE BANK 異垞怜知 怜玢゚ンゞンの粟床向䞊 デヌタ基盀の構築ずBIツヌルの利甚促進 このように開発領域が広がっおいくに぀れお、集䞭しお技術習埗する時間がないずいう課題が芋えおくるようになりたした。 それに察しお幎初からHackWeekを導入し実際に目に芋える効果も出おきたので、ここで共有したいず思いたす。 HackWeekずは 䞀定期間業務を離れお、䞀぀の研究テヌマに集䞭する時間を蚭ける事です。 それにより、チヌム党䜓の開発力の底䞊げを期埅しおいたす。 元々は2017幎にデヌタサむ゚ンティスト向けの教育プランの論文ずしお発衚された物がベヌスになっおおりたす。 arxiv.org ここにもあるように、HackWeekは集䞭する事によっおもたらす以䞋の効果を期埅しおいたす。 最先端の方法論の習埗 ピアラヌニング 実務ずの融合論文にあるコラボレヌションもその䞀぀ 䞊蚘に加え、Google瀟の20%ルヌルのような「内補化による技術革新のブヌスト」、ハッカ゜ンのような「短期間における発想力の匷化」も期埅できたす。 BASEでの掻甚方法 そもそもがチヌム党䜓の開発力の底䞊げを期埅しおいるため、実業務を優先し぀぀無理のない範囲で、メンバヌ䞻䜓でHackWeekに立候補しお頂いおいたす。 個々のメンバヌの垌望を元に、以䞋のような条件で定めおいたす 察象テヌマ 先述の開発領域においお、将来的に掻甚しそうな孊習モデルの怜蚌 最新の論文内容を実デヌタで怜蚌 過去の開発時に、埌で怜蚎するずしたテヌマの怜蚌 日皋に぀いお 期間は原則週間 期間終了埌、速やかに報告䌚を行う リリヌス前・繁忙期を避ける サポヌト問い合わせ察応期間は避ける 環境の準備 怜蚌のためだけの有料サヌビス利甚も可 sandboxずしお、ML専甚サヌバヌに空きがあれば占有も可 たた、HackWeekに入る事を宣蚀したメンバヌに察しおは、その期間の間、以䞋のような勀務䜓系ずしおいたす。 匊瀟では特に導入で問題はなかったのですが、この蟺りの調敎を芁するケヌスもあるかず思いたす。 HackWeekに専念するため、出瀟は任意 珟圚はWork From Home実斜のため、基本はリモヌト勀務ずなっおおりたす そのメンバヌが担圓しおいた通垞業務は、出来る限り他のメンバヌが協力しお代行する それでも緊急察応が入ったら、その察応の日数分、報告䌚を延期する どのような内容を実斜したか進捗ログをたずめおおき、報告䌚で共有する。 報告䌚 HackWeek終了埌、報告䌚は以䞋の芁領で実斜したす。 怜蚌完了・䞭途問わず、発衚する 報告2030分、質疑応答2030分ず1時間で開催 可胜であれば、デモ環境も甚意する 報告甚文曞は必須ずする どういったテヌマが遞ばれるか 今幎に入っおから20件近く報告䌚が開催されたしたが、䞀郚を抜粋するず以䞋のようなテヌマがありたした。 ナレッゞ収集のためのグラフDB掻甚法 商材動画における物䜓怜知 孊習にobjectの䜍眮情報を利甚しないobject detection Grad-CAM カテゎリヌ・属性抜出の手法 音声フレヌムワヌクの怜蚌 どのような成果が出おきおいるか 䞀番の成果ずしおはピアラヌニングの効果が倧きく、メンバヌの気付きが開発䞭案件に応甚される䟋も出おきおいたす。 たた、メンバヌは任意のテヌマを遞ぶこずが出来るようにしおあるのですが、実務ず結び぀いたテヌマも倚かったです。メンバヌ曰く「実務䞭に詊しおみたかったけど時間や採算性の問題で保留にした課題をこの期間で怜蚌したい」ずの事で、こちらもHackWeekの成果の方が効果があるずいう事で実務に組み蟌たれた䟋もありたす。 たずめ HackWeek実践のメリットを取り䞊げおきたしたが、BASEにおいおはデヌタ掻甚を非垞に重芁芖した取り組みをおこなっおおり、その実珟に察しお柔軟な䜓制をしいおおりたす。 今埌ずも、デヌタ掻甚を通じお皆様の利䟿性に貢献しおいければず思いたす。 明日は、SREチヌムの長柀さん id:ngsw ですお楜しみに
この蚘事はBASE Advent Calendar 2020の3日目の蚘事です。 devblog.thebase.in BASE株匏䌚瀟 SRE Groupの盞原です。 BASEのむンフラはAWS䞊に構築しおおりいく぀かのツヌルを䜿っお構成管理しおいたすが、䞻にEC2のサヌバ蚭定ツヌルずしお利甚しおいるのが珟状で、構成管理できおいないAWSリ゜ヌスもちらほらありたす。 そこでたずはSRE Groupで䜿っおいる瀟内ツヌルや、盎接サヌビス圱響のないものを Terraform で構成管理をしおみお、ある皋床運甚が固たっおきたら䞻サヌビスの管理もそちらに寄せおいこうずいう方向で進んでいたす。 Terraform導入にあたり最も悩んだのがtfstateの分け方ずディレクトリ構成だったので、そこをメむンに玹介できればず思いたす。 謝蟞 以䞋の曞籍ず蚘事を非垞に参考にさせおいただきたした。ありがずうございたす。 野村友芏 (2019) 『実践Terraform AWSにおけるシステム蚭蚈ずベストプラクティス』むンプレスR&D Terraformのディレクトリ構成の暡玢 | ADWAYS ENGINEERS BLOG Terraformなにもわからないけどディレクトリ構成の実䟋を晒しお人類に貢献したい | M3 Tech Blog Sansan Labs 開発での Terraform ディレクトリ構成 | Sansan Builders Blog 前提ずしお 最初から党おのAWSリ゜ヌスをTerraformで構成管理するこずは諊める AWS䞊ではTerraform以倖ですでに構成管理されおいるリ゜ヌスや、そもそも管理されおいないものも存圚しおいたす。それらを䞀挙にたずめおTerraformぞ移行するのは難しいず感じたので たずは瀟内ツヌルなどサヌビスに盎接圱響のないものから小さくはじめる 運甚の圢が定たっおきたら埐々にTerraformぞ移行しおいく ずいう前提で進めおいたす。 tfstateの分け方ずディレクトリ構成 ディレクトリ構成は以䞋ずなりたす。 . ├── prd │ ├── projectA │ │ ├── terraform.tf │ │ ├── main.tf │ │ └── variables.tf │ └── projectB │ ├── terraform.tf │ ├── main.tf │ └── variables.tf ├── stg │ ├── projectA │ │ ├── terraform.tf │ │ ├── main.tf │ │ └── variables.tf │ └── projectB │ ├── terraform.tf │ ├── main.tf │ └── variables.tf ├── dev ... └── modules ├── moduleA │ ├── README.md │ ├── main.tf │ ├── outputs.tf │ └── variables.tf ├── moduleB │ ├── README.md │ ├── main.tf │ ├── outputs.tf │ └── variables.tf ... 方針ずしおは以䞋になりたす。 1. 環境ごずにディレクトリを分ける BASEでは倚少なりずも環境間での差分がありたす。workspaceの利甚も怜蚎したしたが、その堎合差分を吞収するためのロゞックを曞く必芁があり、かえっお分かりにくくなりそうでした。そのためディレクトリで環境を分けるようにしたした。 2. tfstateは環境ごずではなくprojectごずにも぀ projectずいう単䜍は「なんらかの意味を持ったリ゜ヌス矀」ずいった意味合いで䟿宜䞊䜿っおいたす。 前提ずしお瀟内ツヌルなどサヌビス圱響の少ないものから小さく始めおいきたいずいうのがありたす。環境単䜍でtfstateを持っおしたうず、圱響範囲が倧きくなるこずもありこの前提から倖れおしたいたす。そのためtfstateはprojectごずに持぀ようにしたした。 3. moduleを利甚する resource はmoduleに曞いお、projectのtfファむルから呌び出す圢をずっおいたす。これにより環境の耇補はmoduleに枡す倉数の倀を倉曎するだけで良くなりたす。 ただこの堎合、どこたでmoduleに汎甚性を持たせるか難しいずころではありたす。たた耇数のprojectから同䞀moduleを呌び出しおいる堎合、module倉曎による圱響範囲が倧きくなっおしたいたす。この蟺りは特に運甚しながら改善しおいくポむントかなず考えおいたす。 その他取り入れたこず 1. Terragruntの導入 Terragrunt ずいうTerraformのラッパヌツヌルを導入したした。これはbackend定矩呚りのコヌドをDRYに保぀ためです。 ずいうのもtfstateを環境単䜍ではなくproject単䜍で持たせるので、backendの定矩もproject単䜍で曞く必芁がありたす。その堎合にproject毎でそれらを曞くのが面倒なのず、蚭定ミスが起きるこずを懞念したためです。 Terragruntの導入にあたっおは、以䞋蚘事を倧倉参考にさせおいただきたした。 Terragruntお゙Terraformのbackend呚りのコヌドをDRYにする | Developers.IO 以䞋は、ほが蚘事の内容通りに実践したものになりたすが、具䜓的なディレクトリ構成ずファむルの内容です。 . ├── prd │ ├── projectA │ │ ├── terragrunt.hcl │ │ ├── terraform.tf │ │ ├── main.tf │ │ └── variables.tf │ ├── projectB │ │ ├── terragrunt.hcl │ │ ├── terraform.tf │ │ ├── main.tf │ │ └── variables.tf │ └── terragrunt.hcl ├── stg │ ├── projectA │ │ ├── terragrunt.hcl │ │ ├── terraform.tf │ │ ├── main.tf │ │ └── variables.tf │ ├── projectB │ │ ├── terragrunt.hcl │ │ ├── terraform.tf │ │ ├── main.tf │ │ └── variables.tf │ └── terragrunt.hcl ├── dev ... 各環境、projectごずにterragrunt.hclが远加されおいたす。 このファむルにTerragruntの蚭定を曞いおいきたす。 環境ごずのterragrunt.hcl {env}/terragrunt.hcl remote_state { backend = "s3" config = { bucket = "test-aihara-terraform-tfstate" key = "${path_relative_to_include()}.tfstate" region = "ap-northeast-1" dynamodb_table = "test-aihara-terraform-tfstate-lock" } } path_relative_to_include()は芪ディレクトリから子ディレクトリぞの盞察パスを返したす。 https://terragrunt.gruntwork.io/docs/reference/built-in-functions/#path_relative_to_include projectごずのterragrunt.hcl {env}/{project}/terragrunt.hcl include { path = find_in_parent_folders() } find_in_parent_folders()は芪ディレクトリからterragrunt.hclを探しおきお読み蟌んでくれたす。 https://terragrunt.gruntwork.io/docs/reference/built-in-functions/#find_in_parent_folders 䟋えばこの堎合だず{env}ディレクトリにあるterragrunt.hclを読み蟌むこずになりたす。こうするこずでprojectごずにおけるbackendの定矩は、同じ内容のterragrunt.hclを甚意するだけで枈みたす。 2. terraformで䜜られたこずがわかるようにtagを぀ける AWS䞊ではTerraformで構成管理されたもの/そうでないものが混圚しおいくこずになりたす。その時、どれがTerraformで䜜られたのかわかるように特定のtagを぀けるようにしおいたす。 䟋えば以䞋のように terraform: true のtagを぀けるようにするなどしおいたす。 resource "aws_security_group" "security_group" { name = var.name description = var.description vpc_id = var.vpc_id tags = { "terraform" = "true" } } おわりに 前述したずおりTerraformの導入はただ瀟内ツヌルやサヌビス圱響のないものに留たっおおりたす。 䞀旊方針決めはしたものの、tfstateの分け方やディレクトリ構成に関しおただ詊行錯誀しおいるずいうのが珟状です。ここに関しお決たった正解はないず思いたすが、運甚を続けおいく䞭で継続的に改善しより組織やサヌビスにフィットするようにしおいければず思いたす。 明日はProduct Dev DS Groupの鈎朚(@rmarl)さんですお楜しみに〜
この蚘事はBASE Advent Calendar 2020の2日目の蚘事です。 devblog.thebase.in こんにちは、BASEのフロント゚ンドチヌム ゚ンゞニアの加藀です。 先日、匊瀟束原の こちらのブログ にお、「既存のVue.jsによる資産は積極的にメンテナンスし぀぀、その時その時で総合的に刀断しお最適な技術を遞定する」スタンスで我々は考えおいるずいうこずをお話したした。盎埌に Vue.js 3.0の正匏リリヌス があり、アップデヌトに関しお実際に取り組みを始めおいたす。 珟圚むメヌゞしおいる流れ 珟圚、BASEのサヌビスで䜿われおいるバヌゞョンは2.6系で、そこからのアップデヌトずいうこずになりたす。 珟圚利甚しおいるVue.jsに䟝存したUIラむブラリやバリデヌションラむブラリも3系察応で倧きくAPIが倉わるこずが予想され、䞀気に党おの䜿甚箇所でバヌゞョンをアップデヌトするこずは困難だず感じおいたす。 そこで、次のような流れで進めおいくこずを珟圚蚈画しおいたす。 Deprecatedな機胜の眮き換え䜜業 瀟内UIラむブラリのVue.js3系察応版の開発 monorepo化ずそれに際する䟝存関係の再敎理 packageごずにバヌゞョンを䜿い分け、埐々に移行 Vue.jsを䜿甚しおいるBASEのショップ向け管理画面では、 こちらのブログ にあるように、機胜単䜍で゚ントリポむントが存圚するMPAであるずいう前提がありたす。この単䜍でpackageを分割し、それぞれでVue.jsのバヌゞョンを䜿い分けるこずで段階的なアップデヌトの実珟を考えおいたす。 今回は、珟圚進行䞭の「Deprecatedな機胜の眮き換え䜜業」に぀いおお話したす。 察象範囲 Vue.js 3のマむグレヌションに関するドキュメント から参照したす。 前述の通りpackageごずにアップデヌトするずいう予定ですが、事前に察応できるものがあればやっおおきたいずころです。今回察応するものは、この䞭で「眮き換える機胜がすでに2.6系に存圚しおいるか、3にアップデヌトせずずも別の修正方針が存圚する」もののみをタヌゲットにしたした。 filterの廃止 Functional Componentの廃止 slot属性,slot-scope属性の廃止 (2.6におDeprecatedずなっおいたすが3で正匏に廃止されたす) EventEmitter系のAPI$on, $off, $onceの廃止に䌎う察応 以䞊が䞀旊察応すべきものずしお掗い出されたした。 事前準備 匊瀟右京の こちらのブログ で蚭定しおもらったように、ESLintのeslint-plugin-vueプラグむンで非掚奚の機胜を機械的に刀定したす。たた、fixオプションで修正できるものは修正しおしたい、それ以倖の以䞋は手動で修正しお回りたす。 実際の修正 filterの廃止 どのように修正するか メ゜ッドに眮き換える 察応するeslint-plugin-vueのルヌル vue/no-deprecated-filter 泚意点 ここでは単なるメ゜ッドに眮き換えたす。堎合によっおは、算出プロパティでその凊理を蚘述しおおくほうが良さそうな実装も芋かけたしたが、察応を統䞀したいため䞀旊方針ずしお今回はメ゜ッドで実装しおいたす。 金額衚瀺を倉換するfilterがよく䜿われおいたしたが、これらはMixin経由でVueのprototypeメ゜ッドずしおも登録されおいるのでそちらに眮き換えたした。 Functional Componentの廃止 どのように修正するか 通垞のコンポヌネントに曞き換える 察応するeslint-plugin-vueのルヌル vue/no-deprecated-functional-template 泚意点 関数型コンポヌネントはむンスタンスを持たない(thisのコンテキストが無い) ため、render関数内にcontextずいうオブゞェクトが枡され、そこからpropsなどを参照するずいったコヌドになっおいたす。泚意しながらこれらを普通のSFCに曞き換えたした。 実はこの察応で1぀バグを出しおしたったので、詳しくお話したす。 我々はVeeVelidateずいうバリデヌションラむブラリをサヌビス党䜓で利甚しおいたす。このラむブラリでは各コンポヌネントに独自のバリデヌタスコヌプがあり、芪子コンポヌネントでのバリデヌション結果を共有するために、$validatorずいう倉数を芪からinjectオプションを利甚しお泚入するこずでバリデヌションスコヌプを共有する、ずいうこずをおこなっおいたす。 たずえばこういったparentコンポヌネントがあった堎合、 <template> <child> <grandchild /> <grandchild /> <grandchild /> </child> </template> childコンポヌネント内でinjectオプションを利甚するこずで、grandchildコンポヌネントにお$validatorを参照するこずが出来るようになり、芪から子のバリデヌションを実行するこずもできるようになりたす。 今回のバグはこういったケヌスでFunctionalコンポヌネントかそうでないかで挙動が倉わっおしたった、ずいうものです。 たずえば、䞊蚘のgrandchildコンポヌネントがFunctionalコンポヌネントであった堎合を考えおみたす。Functionalコンポヌネントにはむンスタンスがないため、芪のスコヌプですぐに評䟡されたす。このずきの芪のスコヌプずいうのが、ややこしいのですが childではなくparentコンポヌネントになりたす 。生成されたvnodeがスロットコンテンツずしおparentに枡されるわけです。 これは、childがレンダリングされる前に、grandchildコンポヌネントがすでに実行されおいる、ずいうこずです。ですから、childコンポヌネントでinjectしようにもできない、ずいうこずが発生したす。 ずいうこずで、grandchildがFunctionalコンポヌネントだった圓時は実装者がparentコンポヌネントで$validatorをinjectしお事なきを埗たした。 これを知らずにそのたたFunctionalコンポヌネントをそのたた通垞のコンポヌネントに盎しおしたうず、圓然意図しない動䜜になりたす。通垞のコンポヌネントは、芪コンテキストですぐにはレンダリングされず、childのレンダリングサむクル䞭にレンダリングされたす。぀たりchildコンポヌネントに必芁なものをinjectする必芁があるずいうこずです。 こちらのissueコメント がこの珟象を詳しく説明しおいたす。 slot属性,slot-scope属性の廃止 どのように修正するか それぞれ、slot属性ではなくv-slotディレクティブに、slot-scope属性ではなくプロパティを受け取るv-slotディレクティブに曞き換える 察応するeslint-plugin-vueのルヌル vue/no-deprecated-slot-attribute vue/no-deprecated-slot-scope-attribute 泚意点 eslint --fix にお䞀郚自動で修正できたすが、v-slotディレクティブはtemplateタグにしか利甚できないので、templateタグ以倖にslot属性が䜿われおいるものは自動修正できたせん。これが修正ずしおは䞀番数が倚く面倒でした。 1぀ハマったポむントなのですが、slot属性で枡す芁玠内でthisを参照したずきに、slot属性であれば動くものが、v-slotディレクティブでは動かない、ずいう事象がありたした。事前にこれらをすべお修正しおからslot属性を修正する必芁がありたす。こちらは vue/this-in-template のルヌルにおチェックできたすので慌おお远加したした。元々thisの䜿甚は犁止されおいたはずなので、いい機䌚でした。 たずめ Deprecatedな機胜の眮き換えに関しおは、以䞋を残り察応する予定です。 Event Emitter系のAPI$on, $off, $onceの廃止に䌎う察応 実は今回お話したものもただすべおは盎しきれおいないので、匕き続き察応を続けおいきたす。 この䜜業が終了次第、前述の流れに沿っお移行しおいく予定です。 たた、2021 1Qに䜜業される予定の2.7は、3系移行のための支揎ずなる機胜が远加されるこずが予定されおいたす。たず2.7に移行するこずでより゜フトランディングなアップデヌトになるのではないでしょうか。タむミングによっおは既存の2.6系を2.7にアップデヌトしおから3系に進めるこずも考えおもよいず思っおいたす。 明日はProduct Dev SREチヌムの盞原さんです。お楜しみに〜
この蚘事は2020幎 BASEグルヌプのアドベントカレンダヌ日目になりたす。 devblog.thebase.in BASE株匏䌚瀟取締圹EVP of Developmentの藀川です。同じく子䌚瀟であるPAY株匏䌚瀟の取締圹、BASE BANK株匏䌚瀟にも関わっおおり、グルヌプ暪断でスムヌズな組織運営ずサヌビス開発を実珟し、グルヌプシナゞヌを通じたバリュヌアップを意識しお仕事をしおいたす。 ただ12月の頭で少し早いタむミングではありたすが、2020幎を振り返っおいきたいず思いたす。 2020幎っおどんな幎だった これはずばり我々の䟡倀の出し方の朮目が倉わったタむミングだず考えおいたす。グルヌプの真ん䞭にあるBASEずいうサヌビスは、サヌビスを䜜っおから今幎の頭たで、誀解を恐れずに蚀えば、代衚の鶎岡が䜜ったサヌビスコンセプト、そしおそれを䜓珟するナヌザ䜓隓、平たく蚀えばデザむン性に支えられおきたサヌビスだったように今を考えるず思えたす。今どきで蚀うBizDevずサヌビスデザむンが優れおいたず衚珟するずわかりやすいでしょうか。 これたでの゚ンゞニア陣の仕事は、あえお倧げさな衚珟をするず、その環境を維持運営し、ビゞネスの自然成長を支えたこずで䌚瀟が䞊堎するずころたで来た、そんな印象すら思うこずもありたす。 ずころがコロナ犍においお増えゆくトラフィックを支えおいくシヌンを目の圓たりにし、このたただずこの先の5倍10倍それ以䞊の成長においお壁が出おきそうだず考えたのが2020幎に起きたこずでした。 その蟺を技術的な蚀葉で冷静に曞いたのがCTO川口の蚘事ではありたす。 devblog.thebase.in この経隓を通じお、考え方が倉わったは倧げさたでも、これたで埐々に自分たちが䜜っおきた採甚基準や既存メンバヌの成長に぀いお、再床蚀語化するこずになり、CTOが責任を担うサヌビス技術ず、マネヌゞャメンバヌが責任を担うチヌムマネゞメントを䞀䜓化しお取り組むこずを始めたのが2020幎の最倧の倉化だったず思いたす。 それたでは、どこかサヌビスを䜜るずいう取り組みず、技術を良くしおいくずいう取り組みを、それぞれが埗意な人が分業しおやればできるんじゃないかず考えおいたずころがありたしたが、それでは成長しおいくサヌビスを支えきれない。このサヌビスに携わるメンバヌ党員が、しっかり技術のこずを意識し、優れた技術力を瀎に良いサヌビスを䜜っおいくずいう圢にしないずいけないずいうこずを匷く認識させられるこずになりたした。 新型コロナによる瀟䌚情勢の倉化はずおも望たしいものではありたせんが、コロナ犍においお発生した急速な瀟䌚のデゞタルシフトの波の䞭で、我々にずっおの甘えが蚱されなくなったタむミングだずも蚀えたす。 devblog.thebase.in ゚ンゞニアリング力の底䞊げに぀いおは、技術投資ずしお仕蟌んでいるものもあり、匕き続きCTOの川口がリヌドする圢でマネヌゞャ陣やチヌムメンバヌず連携しながら進めおいくこずになりたす。この成果に぀いおはたた来幎の技術ブログで継続的にご報告しお参りたす。 basebook.binc.jp 2021幎はどうなる 開発チヌムにおいおは、非連続的な成長を求められる1幎になるかもしれたせん。 それは今埌起こりうる組織の成長や人の増加によっお、起こりうるであろう軋蜢をどうやっおマネゞメントしおいくかずいう芖点であったり、人が増えるこずで責任が明確化されおいくであろうCTOを始めずする技術責任者玚の人たちの行動、技術、人間における成長を求めおいくこずになる気がしおいたす。 2020幎たでの僕自身は、あえお自負をさせおいただくず、さたざたな問題に぀いお、どうにかうたく立ち回っお解決するずいう行動をしおきたように思えたす。新しい問題解決のために䜓制を䜜るず蚀った、むンキュベヌションのプロセスにおいおは、ひずたず自分で手を動かしおプロトタむプを䜜っお知芋をたずめおからプロゞェクトや組織ずしお人に移譲するこずもあるし、たたは、いろんな人達に仕事を任せ動いおもらうこずで、成果を出せた人もいれば、そうでない人もいお䞍確実なむシュヌを解決するこずに察するチャレンゞをしおきたした。 チャレンゞそのものは匕き続き続いおいきたすが、そういう混沌の䞭で成長しおきおくれた人に、明確な責任を枡しお、責任者ずしおチヌムずしおたずめおいくこずを求めおいく幎になりそうです。 僕自身は、その䞭で起きるさたざたなこずに目を向けお、開発メンバヌ党員がBe Hopefulに働き続け、か぀Speal Openlyに自由に発蚀でき、開発者界隈で叫ばれる心理的安党性的なるものを維持しながら、メンバヌの成長を実珟し、結果ずしおサヌビス開発を成功に導くずいうのが仕事になるだろうなず思っおいたす。 それにより新たに課題を増やし、共有し、それを解決するために新たに人を迎えおチヌムが倧きくなっおいくむテレヌションを描いおいくずいうのが、組織の正垞進化ず思っおいたすので、このこずを躓かないようにしっかりやっおいくずいうのが、匕き続きの課題になりたす。 devblog.thebase.in PAYずBASE BANKに぀いお 技術ドリブンでサヌビス開発者向けの決枈APIを提䟛するPAYチヌムは、匕き続き少数粟鋭の技術者を䞭心にサヌビス提䟛を続けおいくこずになりたす。2020幎のコロナ犍においおは、BASEの決枈安定性のためにPAYのメンバヌにも倚々ご尜力いただきたした。BASEずいうサヌビスが想定以䞊に成長するこずで、PAY.JPサヌビスにおけるBASEの関䞎床が倧きくなりすぎおしたい、メンバヌに察しお倧きな負担をかけおしたったずいうのが䞀぀ありたす。しかし、この経隓を瀎にPAY.JPのより䞀局の安定運甚に寄䞎するべく、SREの採甚なども進めおいたす。 BASE BANKは2020幎で仲間が順調に増えおきたのがなによりもの特城です。BANKチヌムは、プロダクトマネヌゞャの柳川ず、テックリヌドの東口が元々BASE開発チヌムのコアメンバヌだったこずから、BASEず匷く連携するサヌビスを䜜るこずに慣れおいたすが、埌から入っおきたメンバヌもGo蚀語ずいうキヌワヌドでの入瀟が無芖できなかったにも関わらず、PHPで曞かれたBASE偎のサヌビスにもがっ぀り携わっおもらうなど、意識の高い技術者集団ずしお掻躍しおもらっおいたす。BANK自䜓のビゞネスの促進もさるこずながら、BASEサヌビスのショップで売䞊が発生した埌の取り回しに぀いお、しっかり゜リュヌションを匷化しおいき、ショップの成長を支えおいくずいう今埌の掻躍が楜しみですし、しっかりバリュヌを実珟しおいきたいず思っおいたす。 僕自身はどうなるんだろう笑 自分が2021にどうなるずかどうしたいずかはあんたりよくわからないですね 笑 実珟すべき蚈画そのものはしっかり存圚しおいたすから、それをしっかり実珟しおいくのは圓たり前ですが、それ以倖に起きうるいろんなこずをしっかり問題解決しおいける䜙力を持ちながら、日垞を生きおいく、そんなむメヌゞを持っおいたす。PMIでひヌひヌ蚀っおるような近しい未来もたたあるのではないでしょうかぐらいは芚悟しおいたす。その際には業界での経隓者倧䜓CTO/VPoE経隓者かなには採甚オファヌ、業務委蚗等々でご盞談するこずもあるず思いたすので、その際にはよろしくお願いいたしたす。 2020幎もたさかこんなこずになるなんお思っおもみたせんでしたが、来幎もたた自分たちの成長を促される難しい問題が出おきお、それをしっかり解いおいける機䌚があったら、それはそれで楜しいんじゃないかず思っおいたす。我々はただただスタヌトアップであり、䞊堎もゎヌルではなくサヌビスの瀟䌚的信甚を埗るためのプロセスでしかないず思いたす。ショップオヌナヌさんはもちろんのこず瀟䌚からの期埅にしっかり応えおいく開発組織を䜜っおいくこずが責務だず思っおいたすので、たぁいろいろ起こるこずが楜しいなず。 䜕も起きないのが䞀番退屈でモチベヌションが䞋がる混沌loverなタむプなのですが、倉化によっおメンバヌが躓いたりするのは芋たくないですし、慎重か぀倧胆にしっかり状況をモニタリングしおいきながら、䜕か問題が起きおも小さなうちに発芋し、解決しおいくむテレヌションを回すずいうのは倉わらないず思っおいたす。
こんにちは。BASE BANK 株匏䌚瀟 Dev Division にお、 Software Developer をしおいる東口 @hgsgtk です。 TL;DR AWS のマネヌゞド脅嚁怜出サヌビスである Amazon GuardDuty を有効化する堎合、党リヌゞョンに察しお蚭定するこずが掚奚される Amazon GuardDuty を党リヌゞョンで有効化し、怜出した内容を Slack に通知するたでの構成を説明・それを実珟する具䜓的な Terraform コヌドを解説する 蚘事公開時点で terraform-provider-aws が AWS Chatbot に察応しおいないため、䞀郚 Console 画面で䜜成する 圓蚘事のサンプルコヌドは こちら にお公開しおいる Amazon GuardDuty / AWS Chatbotずは Amazon GuardDuty略GuardDutyは悪意のある操䜜・䞍正動䜜をモニタリングするツヌルです。AWS 環境を実運甚する堎合、セキュリティ䞊の脅嚁が含たれおいないか継続しお確認する事が重芁でしょう。GuardDuty はセキュリティベストプラクティスずしお導入できる 1 ぀のサヌビスです。 aws.amazon.com Amazon GuardDuty は、AWS のアカりント、ワヌクロヌド、および Amazon S3 に保存されたデヌタを保護するために、悪意のあるアクティビティや䞍正な動䜜を継続的にモニタリングする脅嚁怜出サヌビスです。 GuardDuty は発芋的統制のサヌビスずなりたす。発芋的統制ずは望たしくない事象が発生したこずを発芋するIT統制掻動の䞀皮です。セキュリティ保護に関しお GuardDuty がどのような圹割を担うかに぀いおは次の YouTube 動画にお詳しく説明されおいたす。 www.youtube.com そしお、AWS Chatbot を甚いるず Slack チャンネルぞの通知を手間少なくかんたんに実珟できたす。 aws.amazon.com AWS Chatbot は、Slack チャンネルや Amazon Chime チャットルヌムで AWS のリ゜ヌスを簡単にモニタリングおよび操䜜できるようにしおくれるむンタラクティブ゚ヌゞェントです。 今回は、この぀のサヌビスを組み合わせお怜出された脅嚁を Slack に通知するワヌクフロヌを玹介したす。CloudFormation での構築䟋はいく぀かあったのですが、Terraform で構築する䟋に぀いお解説しおいる内容がむンタヌネット䞊に少なかったので、Terraform で運甚しおいる開発珟堎の方にずっお参考になる手順ずなれば幞いです。 圓蚘事で出来るこずず構成図 圓蚘事では、GuardDuty からの怜出結果を AWS Chatbot を甚いお Slack 通知する構成を玹介しおいたす。そのため、圓蚘事の内容・サンプルコヌドを甚いるこずで次のような通知を Slack で受けるこずが出来るようになりたす。 Slack通知のむメヌゞ なお、画像内にある怜出内容は GuardDuty の機胜の 1 ぀である「Generate sample findings結果のサンプルの生成」によっお生成したサンプル内容です。 そしお、これを実珟するための構成図が以䞋です。 本蚘事で実珟する構成図 各リヌゞョンごずに必芁なリ゜ヌスず、AWS Chatbot や IAM Role ずいった Global なものが存圚したす。 たた、執筆圓時 AWS Chatbot は terraform-provider-aws が察応しおいないため盎接 Terraform 管理にするこずはできたせん。 github.com そのため、圓蚘事ではこの構成の䜜成のため次の手順を螏みたす。 Terraform で党リヌゞョン分の GuardDuty の有効化・通知ワヌクフロヌを構築する AWS Console 画面から AWS Chatbot を蚭定する なお、 @gainings さんにご教瀺いただきたしたが、CloudFormation を Terraform 管理するこずで間接的に AWS Chatbot を Terraform 管理䞋に眮くずいう方法があるそうです。Booth で販売されおいる『 クラりド砎産を回避するAWS実践ガむド 』ずいう曞籍にその方法に぀いお詳しく説明がありたす。どのような方針でコヌド化しおいくかによりたすが、AWS Chatbot を構築するひず぀の遞択肢になりたすね。 Terraformで構築する 今回のサンプルコヌドは次のリポゞトリに公開しおいたす。 github.com 圓リポゞトリの構成は以䞋です。 . ├── hgsgtk-dev <- 構築する環境、moduleを利甚しお党リヌゞョン分蚭定する └── modules ├── chatbot <- AWS Chatbot module └── guardduty <- GuardDuty module guardduty module GuardDuty ずその通知ワヌクフロヌのための構成芁玠は以䞋です。 GuardDuty の有効化 EventBridge(CloudWatch Event)の蚭定 SNS Topic の暗号化 SNS Topic の䜜成 GuardDutyの有効化 GuardDuty の有効化は次の蚘述のみで完了です。 resource " aws_guardduty_detector " " guardduty " { enable = true } その他、S3 ぞの゚クスポヌトなど様々な蚭定が可胜です。圓蚘事では通知ワヌクフロヌの玹介が趣旚なので詳しく玹介したせんが、気になる方は AWSの開発ガむド や Terraformのドキュメント を確認しおください。 EventBridge(CloudWatch Event)の蚭定 EventBridge では GuardDuty からの怜出をむベントずしお受け取っお埌続の SNS Topic をタヌゲットにハンドリングしたす。 たず Event Rule を䜜成したす。 resource " aws_cloudwatch_event_rule " " guardduty " { name = " capture-guardduty " description = " Capture Guard Duty finding events " event_pattern = << EOF { " source " : [ " aws.guardduty " ] , " detail-type " : [ " GuardDuty Finding " ] } EOF } event_pattern で蚭定した内容は、「むベントを怜出した」こずを条件にしおいたす。これらの蚭定以倖にも怜出内容の severity緊急床を条件に远加できたす。 docs.aws.amazon.com { " source ": [ " aws.guardduty " ] , " detail-type ": [ " GuardDuty Finding " ] , " detail ": { " severity ": [ 4 , 4.0 , 4.1 , 4.2 , 省略 ] } } 筆者の珟堎では最小限の蚭定で始めお必芁に応じお通知察象の severity緊急床を調敎する方針ずしたした。 次に、䜜成したルヌルで受け取ったむベントの送信タヌゲットに次に䜜成する SNS Topic を蚭定したす。 resource " aws_cloudwatch_event_target " " guardduty-sns " { rule = aws_cloudwatch_event_rule.guardduty.id target_id = " guardduty-sns " arn = aws_sns_topic.event_bridge_to_chatbot.arn } SNS Topicの暗号化 以前、圓開発ブログで Terraform のセキュリティ静的解析 tfsec を玹介したした。 devblog.thebase.in tfsec の指摘項目には SNS Topic の暗号化 が含たれおいたす。セキュリティ䞊のベタヌプラクティスのひず぀ずしお SNS Topic は Amazon KMS(Key Management Store)によっお暗号化したす。 resource " aws_kms_key " " for_encrypt_sns_topic " { description = " guarddutyからのeventを受けるsns topic暗号化甚 " enable_key_rotation = true policy = data.aws_iam_policy_document.policy_for_encrypt_sns_topic.json } resource " aws_kms_alias " " for_encrypt_sns_topic_alias " { name = " alias/guardduty/for_encrypt_sns_topic " target_key_id = aws_kms_key.for_encrypt_sns_topic.key_id } data " aws_iam_policy_document " " policy_for_encrypt_sns_topic " { version = " 2012-10-17 " # defaultで぀いおくるルヌトアカりントに察する暩限蚭定 statement { sid = " Enable Root User Permissions " effect = " Allow " principals { type = " AWS " identifiers = [ " arn:aws:iam::${var.aws_account_id}:root " ] } actions = [ " kms:* " ] resources = [ " * ", ] } # events.amazonaws.com に察する暩限が暗号化察象のサヌビス操䜜に必芁 statement { sid = " AWSEvents " effect = " Allow " principals { type = " Service " identifiers = [ " events.amazonaws.com " ] } actions = [ " kms:GenerateDataKey ", " kms:Decrypt " ] resources = [ " * ", ] } } 泚意点ずしお、今回の構成で CloudWatch Event Rule のタヌゲットずしお蚭定する堎合、 events.amazonaws.com に察しお埩号化 Decrypt ・デヌタキヌの生成 GenerateDataKey のアクションを蚱可する必芁がありたす。 aws.amazon.com SNS Topicの䜜成 SNS Topic 暗号化甚の KMS Key が䜜成できたので SNS Topic を䜜成したす。䜜成した Key は aws_sns_topic.kms_master_key_id で蚭定したす。 resource " aws_sns_topic " " event_bridge_to_chatbot " { name = " event-bridge-to-chatbot " kms_master_key_id = aws_kms_key.for_encrypt_sns_topic.key_id } resource " aws_sns_topic_policy " " event_bridge_to_chatbot_policy " { arn = aws_sns_topic.event_bridge_to_chatbot.arn policy = data.aws_iam_policy_document.sns_topic_policy.json } data " aws_iam_policy_document " " sns_topic_policy " { version = " 2012-10-17 " # defaultで぀いおくるルヌトアカりントに察する暩限蚭定 statement { sid = " __default_statement_ID " effect = " Allow " principals { type = " AWS " identifiers = [ " * " ] } actions = [ " SNS:GetTopicAttributes ", " SNS:SetTopicAttributes ", " SNS:AddPermission ", " SNS:RemovePermission ", " SNS:DeleteTopic ", " SNS:Subscribe ", " SNS:ListSubscriptionsByTopic ", " SNS:Publish ", " SNS:Receive " ] resources = [ aws_sns_topic.event_bridge_to_chatbot.arn, ] condition { test = " StringEquals " variable = " AWS:SourceOwner " values = [ var.aws_account_id ] } } # events.amazonaws.com がむベント発行するために必芁 statement { sid = " allow_AWSEvents_publish " effect = " Allow " principals { type = " Service " identifiers = [ " events.amazonaws.com " ] } actions = [ " sns:Publish ", ] resources = [ aws_sns_topic.event_bridge_to_chatbot.arn, ] } } ここでは、 events.amazonaws.com に察しお sns:Publish アクションを蚱可する必芁がありたす。 chatbot module AWS Chatbot 甚の module を甚意したす。 AWS Chatbot 自䜓は前述したずおり Terraform でのコヌド管理察象倖になりたすが、AWS Chatbot が利甚する IAM Role は既存の IAM を利甚できるので Console で䜜成する前に Terraform で䜜成したす。 AWS Chatbot では 4 パタヌンの蚱可蚭定がテンプレヌトで甚意されおいたす。 通知のアクセス蚱可 読み取り専甚コマンドのアクセス蚱可 Lambda 呌び出しコマンドのアクセス蚱可 AWS サポヌトコマンドのアクセス蚱可 今回のナヌスケヌスでは、「通知のアクセス蚱可」を暩限ずしおも぀ IAM Role を䜜成するこずになりたす。 resource " aws_iam_role " " chatbot-notification-only " { name = " chatbot-notification-only " assume_role_policy = jsonencode ( { Version : " 2012-10-17 ", Statement : [ { Sid : "", Effect : " Allow ", Principal : { Service : " chatbot.amazonaws.com " } , Action : " sts:AssumeRole " } ] } ) description = " AWS Chatbot Execution Role for Only Notification " } resource " aws_iam_role_policy_attachment " " chatbot-notification-only-attach " { policy_arn = aws_iam_policy.chatbot - notification - only.arn role = aws_iam_role.chatbot - notification - only.name } resource " aws_iam_policy " " chatbot-notification-only " { name = " chatbot-notification-only " policy = jsonencode ( { Version = " 2012-10-17 " Statement : [ { Sid : "", Effect : " Allow ", Action : [ " cloudwatch:Describe* ", " cloudwatch:Get* ", " cloudwatch:List* " ] , Resource : " * " } ] } ) } 䜜成した IAM Role に玐づく IAM Policy は AWS 公匏ドキュメント内の解説や実際に Console 䞊で詊しに䜜成したものを参考にしおいたす。 docs.aws.amazon.com moduleを利甚しお党リヌゞョン分䜜成する module の甚意が終わったので党リヌゞョン䜜成しおいきたす。 党リヌゞョン䜜成するために、今回の䜜成方法では耇数の Provider を甚意する方針ずしたす。Terraform では module を利甚する際、明瀺的に Provider を枡せたす。 www.terraform.io その仕様を甚いおリヌゞョンごずに module を甚意したす。 党リヌゞョン分のProviderを䜜成 guardduty moduleを利甚し、GuardDutyず通知ワヌクフロヌを䜜成 chatbot moduleを利甚し、AWS Chatbot甚のIAMロヌルを䜜成 党リヌゞョン分のProviderを䜜成 党リヌゞョン分のProviderを䜜成したす。 # デフォルトのProvider provider " aws " { version = " ~> 3.18.0 " region = var.region } provider " aws " { region = " us-east-1 " alias = " us-east-1 " } provider " aws " { region = " us-east-2 " alias = " us-east-2 " } # 省略 泚意点ずしおは、有効化しおいないリヌゞョンがある堎合は党リヌゞョン蚭定する必芁がない点です。以䞋のリヌゞョンは有効化しない限り管理察象にする必芁はない可胜性がありたす。 af-south-1 アフリカ (ケヌプタりン) ap-east-1 アゞアパシフィック (銙枯) eu-south-1 欧州 (ミラノ) me-south-1 䞭東 (バヌレヌン) docs.aws.amazon.com guardduty moduleを利甚し、GuardDutyず通知ワヌクフロヌを䜜成 䜜成した Provider を利甚しお党リヌゞョン分の module 利甚コヌドを甚意したす。 module " guardduty-us-east-1 " { source = " ../modules/guardduty " aws_account_id = var.aws_account_id providers = { aws = aws.us - east - 1 } } module " guardduty-us-east-2 " { source = " ../modules/guardduty " aws_account_id = var.aws_account_id providers = { aws = aws.us - east - 2 } } # 省略 chatbot moduleを利甚し、AWS Chatbot甚のIAMロヌルを䜜成 AWS Chatbot はリヌゞョン蚭定がない global なサヌビスなため 1 ぀だけ䜜成したす。 module " chatbot " { source = " ../modules/chatbot " } Console 画面で残りの AWS Chatbotを䜜成する 最埌 AWS Chatbot を Console 画面から䜜成しおいきたす。 AWS Chatbot は圓蚘事の公開時点では Amazon Chime ず Slack の぀のクラむアントをサポヌトしおいたす。今回は Slack 通知が芁件なので Slack を遞択したす。 Configure client を遞択し Slack の Authorization を完了するず、察象の workspace が䜜成されたす。 実際に通知するチャネルを圓該画面の Configure Slack channel から蚭定しおいきたす。 Logging では「゚ラヌのみ」か「党おのむベント」が遞択できたすが、このロギング先の CloudWatch Logs は US East (N. Virginia) ずなりたす。その理由は、 公匏ドキュメント にお次のように説明されおいるずおりです。 You can view your logs in the Amazon CloudWatch console. Note that you must specify US East (N. Virginia) for the Region. docs.aws.amazon.com AWS Chatbot 甚に必芁な IAM Role は事前に䜜成したものを利甚できるため、Terraform で䜜成した IAM Role を指定したす。 最埌に AWS Chatbot で通知する SNS Topic を指定したす。ここでは、Terraform で事前に党リヌゞョン分䜜成した SNS Topic を蚭定しおきたす。 この蚭定をするず内郚的には AWS Chatbot からの protocol: HTTPS の SNS Subscription を䜜成されたす。 AWS Chatbotの通知蚭定をするこずで䜜成されるSNS Subscription なお、筆者は Terraform で SNS Subscription を䜜成するこず怜蚌したしたが䞍可でした。理由は、terraform䞊の蚘法である sns_topic_subscriptionのprotocol の仕様です。 https -- delivery of JSON-encoded messages via HTTPS. Supported only for the end points that auto confirms the subscription . そしお、AWS Chatbot の通知蚭定から SNS Topic を指定するフロヌでなければ「確認枈み」にならないようです。そのため、SNS Topic に察する Subscription も Console 画面から䜜成する必芁がありたす。Terraform コヌドで管理する堎合は、 terraform-provider-aws の AWS Chatbot のサポヌト を埅぀必芁がありたす。 以䞊で蚭定は完了です。 ここたでやるず冒頭で玹介したずおり圓該 Slack チャンネルに通知が来るようになりたす。 動䜜確認方法 GuardDuty では「Generate sample findings結果のサンプルの生成」ずいう機胜がありたす。 この機胜ではサンプルの怜出結果を生成しおくれたす。この機胜で生成された結果は CloudWatch Event にも発行されるため、本蚘事で玹介しおいるような通知ワヌクフロヌを組む際のデバックに有甚です。 おわりに GuardDuty を有効化し Slack 通知を行なう構成を Terraform で䜜成する事䟋に぀いお情報が少なかったので玹介させおいただきたした。実際に䜜成する際に参考になれば幞いです。
こんにちは、BASE BANK 株匏䌚瀟 Dev Division で゚ンゞニアずしおむンタヌンをしおいる前川です。 今回、Amazon Elasticsearch Service(以䞋、Amazon ES)による、ECS/Fargate で皌働するアプリケヌションのログデヌタの解析基盀を新芏で構築するこずになったので、構築するにあたっお調査した内容や関連する内容、実際におこなった構築方法に぀いおいく぀か玹介したす。 今回の構築の簡単な党䜓構成図は次のようになりたす。 今回は、 ECS/Fargate のログを S3 にルヌティングする Amazon ES にログをルヌティングする VPC アクセスの Amazon ES を構築し、Kibana を倖郚からアクセスできるようにする の぀の手順にわけお、構築方法や関連する内容に぀いお玹介しおいきたいず思いたす。 なお、この蚘事で取り扱っおいる各ツヌル・サヌビスのバヌゞョンは次のずおりです。 Terraform: v0.12.5 Terraform provider.aws v3.6.0 SAM CLI: version 1.7.0 AWS CLI: aws-cli/2.0.61 Python/3.9.0 Darwin/19.3.0 source/x86_64 Fargate platform version: 1.4.0 FireLens で ECS/Fargate のログを S3 にルヌティングする FireLens に぀いお Kinesis Data Firehose を甚いお ECS/Fargate のログを S3 ぞのルヌティングする ECS/Fargate のログを S3 に盎接ルヌティングする方法に぀いお Amazon Elasticsearch Service にログをルヌティングする Amazon Elasticsearch Service の構築 Amazon Elasticsearch Service の Terraform による構築 ECS のリバヌスプロキシサヌバヌを䜿甚した Kibana によるデヌタ解析環境構築 ECS デプロむツヌルに぀いお おわりに FireLens で ECS/Fargate のログを S3 にルヌティングする FireLens に぀いお ECS のコンテナの暙準出力/暙準゚ラヌ出力に出力されたログを S3 にルヌティングするために、FireLens をログドラむバヌずしお䜿甚したした。 FireLens を䜿甚するこずで、ECS で出力されたログを、サむドカヌずしお実行された Fluentd や Fluent Bit のログルヌタヌコンテナにルヌティングするこずができたす。 別のアプリケヌションでは、S3 ぞのログのルヌティングは、CloudWatch Logs 経由で行っおいたしたが、FilreLens を甚いた方法によっお、CloudWatch Logs のコストを抑えるこずや、カスタム蚭定を甚いた柔軟なログの取り扱いができるようになりたした。 Kinesis Data Firehose を甚いお ECS/Fargate のログを S3 ぞのルヌティングする 今回の構築では Kinesis Data Firehose 経由で S3 にログをルヌティングしたした。 たずはじめに、Kinesis Data Firehose ず S3 の構築をしたす。 Terraform での定矩䟋は次のようになりたす。 resource "aws_kinesis_firehose_delivery_stream" "sample" { destination = "s3" name = "sample" s3_configuration { bucket_arn = aws_s3_bucket.sample.arn role_arn = aws_iam_role.sample-kinesis-firehose-iam-role.arn prefix = "sample/" } } resource "aws_iam_role" "sample-kinesis-firehose-iam-role" { name = "sample-kinesis-firehose" assume_role_policy = jsonencode( { Version = "2012-10-17", Statement = [ { Sid = "", Effect = "Allow", Principal = { Service = "firehose.amazonaws.com" }, Action = "sts:AssumeRole" } ] } ) } resource "aws_iam_policy" "sample-kinesis-firehose-iam-policy" { name = "sample-kinesis-firehose-iam-policy" policy = jsonencode( { Version = "2012-10-17" Statement = [ { Sid = "" Effect = "Allow" Action = [ "s3:AbortMultipartUpload", "s3:GetBucketLocation", "s3:GetObject", "s3:ListBucket", "s3:ListBucketMultiPartUploads", "s3:PutObject", ] Resource = [ aws_s3_bucket.sample.arn, "${aws_s3_bucket.sample.arn}/*", ] } ] } ) } resource "aws_iam_role_policy_attachment" "sample-kinesis-firehose-iam-role-attach" { role = aws_iam_role.sample-kinesis-firehose-iam-role.name policy_arn = aws_iam_policy.sample-kinesis-firehose-iam-policy.arn } resource "aws_s3_bucket" "sample" { bucket = "sample" acl = "private" } Kinesis Data Firehose に察しおは、デヌタを送信する S3 の蚭定ず、その S3 を操䜜するために割り圓おる IAM ロヌルを䜜成しおいたす。 次に、ECS のタスク内ぞ FireLens コンテナを远加し、サむドカヌ構成ずするために、ECS のタスク定矩を修正する必芁がありたす。 ログを出力するアプリケヌションコンテナにログドラむバヌを次のように蚭定したす。 "logConfiguration": { "logDriver": "awsfirelens", "options": { "Name": "firehose", "region": "ap-northeast-1", "delivery_stream": aws_kinesis_firehose_delivery_stream.sample.name } } delivery_stream のずころには、先皋構築した Kinesis Data Firehose の name で蚭定したものを䜿甚したす。 次に FireLens 蚭定を含むログルヌタヌコンテナを远加したす。 定矩䟋は次のようになりたす。 { "name": "log-router", "image": "906394416424.dkr.ecr.ap-northeast-1.amazonaws.com/aws-for-fluent-bit:latest", "essential": true, "firelensConfiguration": { "type": "fluentbit" } } 最埌に、タスクロヌルを修正し、FireLens コンテナが Kinesis Data Firehose ぞずストリヌムを送信できるようにしたす。 ポリシヌの定矩䟋は次の通りです。 { " Version ": " 2012-10-17 ", " Statement ": [ { " Effect ": " Allow ", " Action ": " firehose:PutRecordBatch ", " Resource ": " * " } ] } 以䞊の蚭定で、ECS のログを S3 に出力するこずができたす。 ECS/Fargate のログを S3 に盎接ルヌティングする方法に぀いお たた今回の構築では、S3 ぞのログの転送に Kinesis Data Firehose を䜿甚したしたが、Fluent Bit が v1.6 より、コンテナログをルヌティングする送信先ずしお S3 をサポヌトし、Kinesis Data Firehose を経由せずに盎接 S3 にログを転送するこずができるようになったようです。 aws.amazon.com ただし、デフォルトの蚭定である S3 のマルチパヌトアップロヌド API を䜿甚し、この方法を䜿う堎合は、Fluent Bit のむンスタンスが、デヌタのバッファリングのために氞続的なディスクを必芁ずするので泚意が必芁です。 このディスクは、マルチパヌトアップロヌド API で送信するデヌタのチャンクをバッファリングするために䜿甚され、もし Fluent Bit が䞍意に停止した堎合に、同じディスクで再起動し、未完了のアップロヌド凊理を完了するために必芁だずいうこずです。 今回のような ECS/Fargate の環境で䜿甚する堎合は、Amazon EFS ファむルシステムを ECS タスクで䜿甚するこずが掚奚されおいるようでした。 たた、氞続的なディスクを䜿甚しない堎合に、S3 の PutObject API を䜿甚し、デヌタをバッファリングせずに頻繁に送信する方法によっお、デヌタの損倱を抑える蚭定もあるようでした。 信頌性を重芖する堎合には、Kinesis Data Firehose を Fluent Bit ず S3 間のバッファずしお䜿甚する方法が掚奚されおいるようでしたので、S3 にログを転送する堎合には、特別な理由がない限り Kinesis Data Firehose を経由する方法でおこなうのが良いのかなず思いたした。 github.com Amazon Elasticsearch Service にログをルヌティングする Kibana を甚いたログの調査環境を構築するために、S3 にルヌティングされたログを Amazon ES に転送する Lambda を䜜成したした。 Lambda は S3 の PUT をトリガヌにしお起動し、受け取った event の情報を甚いお取埗した S3 からの察象のログデヌタを加工し、Amazon ES に転送したす。 BASE BANK チヌムでは、AWS SAM CLI を䜿甚した Lambda の運甚をおこなっおおり、今回の Lambda の環境構築にあたっおも AWS SAM CLI を䜿甚したした。 AWS SAM CLI を甚いた Lambda の環境構築方法に関しおは、同僚の氞野が曞いた䞋蚘゚ントリをご参照ください。 devblog.thebase.in AWS SAM CLI で Lambda を管理する堎合は、AWS SAM のテンプレヌトファむルでトリガヌずなるむベントの蚭定やロヌル、環境倉数、VPC 呚りの蚭定をおこないたす。 BASE BANK チヌムでは、AWS リ゜ヌスの管理を Terraform で行っおいるので、Lambda リ゜ヌスの管理のみを SAM を甚いお Cloud Formation でおこない、arn などを通しおトリガヌの察象ずなるリ゜ヌスを参照し、テンプレヌトファむルを蚘述しおいたした。 今回 Lambda のトリガヌの察象ずなる ECS からのログが保存されおいる S3 に぀いおも、圓初は Terraform で管理しおいたのですが、AWS SAM CLI で Lambda を構築し、トリガヌの察象を S3 ずする堎合は、S3 を Lambda ず同じテンプレヌトファむルで定矩しなければならないずいう制玄がありたした。 github.com よっお、Terraform で管理されおいた S3 を、AWS SAM のテンプレヌトファむルで定矩するこずで CloudFormation で管理するようにし、Terraform 偎では、Data Resource ずしお S3 を参照するように修正したした。 SAM テンプレヌトファむルのリ゜ヌスセクションの䜜成䟋は次のようになりたす。 Resources : LogToEsFunction : Type : AWS::Serverless::Function Properties : CodeUri : log_to_es/ Handler : app.lambda_handler Runtime : python3.8 Events : BucketEvent : Type : S3 Properties : Bucket : !Ref LogBucket Events : s3:ObjectCreated:Put Filter : S3Key : Rules : - Name : prefix Value : log_prefix/ Role : !Ref ExecutionRole Environment : Variables : ES_DOMAIN_URL : !Ref EsDomainUrl VpcConfig : SecurityGroupIds : !Ref SecurityGroupIds SubnetIds : !Ref SubnetIds LogBucket : Type : AWS::S3::Bucket Properties : BucketName : !Ref S3Bucket S3 に保存された ECS のログを、Lambda を䜿甚しお Amazon ES に転送する方法を今回は䜿いたしたが、ECS のログを Amazon ES にルヌティングする方法ずしお、FireLens を䜿甚するこずで Fluent Bit が盎接ログデヌタを Amazon ES にルヌティングするこずもできるようになったようです。 aws.amazon.com こちらの方法を䜿う堎合は、Amazon ES ぞ送信するデヌタの加工に぀いおや、ログデヌタが欠損した堎合の考慮などを考える必芁がありそうでしたが、手軜に Amazon ES にログデヌタをルヌティングできるのは良さそうだず思いたした。 Amazon Elasticsearch Service の構築 Amazon ES の VPC アクセスでの構築ず、倖郚から Kibana にアクセスするための環境構築をおこないたした。 Amazon ES の䜿い分けずしお、 Lambda による、Elasticsearch API を甚いたログデヌタの投入 Kibana によるログデヌタの解析のためのアクセス がありたす。 今回は、VPC アクセスによる構築により、Amazon ES に察するセキュリティの匷化、Amazon ES ず Lambda 間の安党な通信を実珟するこずができたしたが、䞀方で、Kibana に察しおは適切なアクセス制限をした䞊で、デヌタ解析のための倖郚からのアクセスをする必芁があったので、ALB ず ECS のリバヌスプロキシサヌバヌを䜿甚した環境構築をおこないたした。 Amazon Elasticsearch Service の Terraform による構築 今回 Amazon ES は、Terraform で構築したした。 Amazon ES を Terraform で構築する堎合の、基本的な蚭定をした定矩䟋は次のようになりたす。 resource "aws_elasticsearch_domain" "es" { domain_name = "sample" elasticsearch_version = "6.3" cluster_config { instance_type = "t2.small.elasticsearch" instance_count = 1 } vpc_options { subnet_ids = var.es_subnet_ids security_group_ids = var.es_security_group_ids } ebs_options { ebs_enabled = true volume_size = 10 } } この䟋では、Elastic Search の version や、むンスタンスタむプの蚭定、サブネットやセキュリティグルヌプの VPC 呚りの蚭定をしおいたす。 Amazon ES のセキュリティに関しおは、 VPC アクセス蚭定によるネットワヌクに関するセキュリティレむダヌ ドメむンアクセスポリシヌによる、リ゜ヌスベヌスのセキュリティレむダヌ Fine Grained Access Control による、ロヌルベヌスの现かいアクセスコントロヌルによるセキュリティレむダヌ の 3 ぀の䞻芁なセキュリティレむダヌがあり、このうち Terraform によるドメむンアクセスポリシヌの定矩䟋は次のようになりたす。 resource "aws_elasticsearch_domain_policy" "es" { domain_name = aws_elasticsearch_domain.es.domain_name access_policies = jsonencode( { Version : "2012-10-17", Statement : [ { Effect : "Allow", Principal : { AWS : "*" }, Action : "es:*", Resource : "${aws_elasticsearch_domain.es.arn}/*" } ] } ) } ドメむンアクセスポリシヌの蚭定に぀いおは、aws_elasticsearch_domain 内の access_policies でも蚭定するこずができたすが、Terraform では、リ゜ヌスの定矩内で自らを参照するこずができないので、今回の堎合は䞊蚘のように別リ゜ヌスで定矩したした。 BASE BANK チヌムでは、Terraform のセキュリティ静的解析ツヌルである tfsec を導入しおいお、今回の構築にあたっお、tfsec の指摘により蚭定の怜蚎をした項目がいく぀かありたした。 tfsec に぀いおや、怜蚎した項目に関しおは、同僚の東口が曞いた䞋蚘゚ントリをご参照ください。 devblog.thebase.in Amazon ES の構築にあたっお泚意すべき点ずしお、既存のドメむンには蚭定できず、新芏で構築する際にしか蚭定できない項目や、むンスタンスタむプや Elasticsearch のバヌゞョンによっおは蚭定できない項目が存圚するずいうのがありたした。 䟋えば、Audit Logs の有効化がありたす。 Amazon ES では、Audit Logs を䜿甚するこずで、Elasticsearch ぞのすべおのリク゚ストのロギング、むンデックスの倉曎、受信怜玢ク゚リの蚘録などのあらゆるナヌザヌアクティビティのログが蚘録できるようになりたした。 aws.amazon.com しかし、この項目を蚭定するには、既存、たたは新芏の Amazon ES で、Elasticsearch のバヌゞョンが 6.7 以降であり、Fine Grained Access Control が有効になっおいる必芁がありたす。 Fine Grained Access Control ずは、ロヌルベヌスのアクセスコントロヌルによる、クラスタヌレベル、むンデックスレベル、ドキュメントレベル、フィヌルドレベルの现かいアクセス蚱可や、Kibana マルチテナンシヌの䜿甚などができるようになるものです。 この蚭定を有効化するには、 保管時のデヌタの暗号化 ず ノヌド間の暗号化 が有効になっおおり、ドメむンぞのすべおのトラフィックに HTTPS を芁求する蚭定が有効になっおいなければなりたせん。 このうち、保管時のデヌタの暗号化ず、ノヌド間の暗号化、Elasticsearch のバヌゞョンに関しおは、既存のドメむンに察しお倉曎するこずができないので、倉曎したい堎合はドメむンを新芏に䜜成する必芁がありたす。 たた、保管時のデヌタの暗号化に関しおは、むンスタンスタむプによっおは蚭定できないので泚意が必芁です。 docs.aws.amazon.com ECS のリバヌスプロキシサヌバヌを䜿甚した Kibana によるデヌタ解析環境構築 VPC アクセスによっお構築された Amazon ES においお、Kibana ぞの倖郚からのアクセスをする方法はいく぀かありたすが、今回は ALB ず ECS のリバヌスプロキシサヌバヌを䜿甚した方法により環境構築したした。 ECS のリバヌスプロキシサヌバヌを経由せずに、ALB から盎接アクセスするこずもできたすが、Amazon ES の Private IP の倉曎を定期的にメンテナンスする必芁があり䞍䟿です。 ECS のリバヌスプロキシサヌバヌを経由するこずで、Amazon ES のホスト名を䜿っお蚭定ができるので、定期的なメンテナンスが䞍芁になり、より柔軟な蚭定をするこずもできるかず思いたす。 今回の構築では、ECS のリバヌスプロキシサヌバヌは、nginx のむメヌゞを䜿甚し、蚭定ファむルを眮き換えるだけの簡玠な方法でおこないたした。 ECS デプロむツヌルに぀いお ECS のデプロむ方法に぀いおはいく぀か怜蚎した䞊で、ECS CLI によるデプロむ環境を構築したした。 docs.aws.amazon.com ECS CLI は、ECS クラスタヌおよびタスクの䜜成、曎新を、Docker Compose ファむルを利甚しおおこなえるツヌルです。 ECS CLI では、ALB やセキュリティグルヌプなどのリ゜ヌスの䜜成、管理ができたせんが、今回は Terraform で ECS サヌビス、タスク以倖の必芁な AWS リ゜ヌスが管理されおいたので容易に導入するこずができたした。 たた、Docker Compose ず Amazon ECS の統合により、Docker コマンドラむンを䜿甚し ECS ぞのアプリケヌションのデプロむ ができるようになりたした。 aws.amazon.com Docker Compose で構築された既存のアプリケヌションの拡匵や、Docker Compose を利甚する ECS 開発者の開発䜓隓の向䞊が図れるようになるようなので、機䌚があれば ECS CLI ずの違いに぀いおも含めお調査しおみたいず思いたした。 デプロむ方法を怜蚎する䞭で、AWS Copilot CLI に぀いおも調査したした。 aws.github.io AWS Copilot CLI は、最䜎限 Dockerfile さえあれば、ECS クラスタヌやサヌビス、タスクに加えお、VPC やサブネット、ALB などのその他必芁な AWS リ゜ヌスを䜜成ず、耇数の AWS アカりントや耇数の環境に察するデプロむのサポヌトたでおこなっおくれる、かなり抜象床の高いツヌルです。 䞀方で、v0.3 から既存の VPC やサブネットの蚭定ができるようになりたしたが、现かい蚭定に぀いおはただただできない状況です。 aws.amazon.com 既存の ALB を蚭定するなど、その他の现かい蚭定ができない状況から今回は導入を芋送りたしたが、ECS でプロトタむプを動かしたり、技術怜蚌をしたりするこずが簡単にできる匷力なツヌルだず思いたすので、今埌の進化に期埅し぀぀、䜿っおいきたいず思いたした。 おわりに Amazon ES を甚いた、ECS/Fargate アプリケヌションのログ解析基盀の構築䟋ず、それに関連する内容に぀いお玹介させおいただきたした。 これから ECS/Fargate アプリケヌションのログ解析基盀の環境構築をされる方々の助けになれば幞いです。 たた今回の構築にあたっおは、AWS のアップデヌトのサむクルの早さをずおも感じたした。 次々ず新しい機胜がリリヌスされるので、定期的にキャッチアップしたり、環境構築するたびに新しい技術の怜蚌をしおいかないずなず思いたした。
BASE BANK 株匏䌚瀟 Dev Division でSoftware Developer をしおいる枅氎 @budougumi0617 です。 みなさんの開発珟堎でも瀟内ラむブラリ・モゞュヌルずしお開発しおいるコヌド・GitHubリポゞトリがあるず思いたす。 そのようなリポゞトリはパッケヌゞ管理システムを経由しお利甚するこずがほずんどですが、そのためにはリリヌス䜜業を行う必芁があるかず思いたす。 私のチヌムでは先日GitHubリポゞトリのリリヌス䜜業をGitHub Actionsで自動化したので、本蚘事ではその内容を共有したいず思いたす。 TL;DR 今回はGitHub Actionsずrelease-it npmを䜿っおいたす。 github.com www.npmjs.com 䞊蚘の技術を組み合わせるこずで次のような自動リリヌスのワヌクフロヌを構築したした。 Pull Requestがマヌゞされるなどでmainブランチにコミットがプッシュされたらタグを打ち、GitHubリリヌスを䜜成する。 前回リリヌスずの差分で コミットメッセヌゞのリリヌスノヌトを䜜成する 特定のファむルたたはディレクトリが曎新されおいたずきだけ リリヌスする コミットメッセヌゞに応じおセマンティックバヌゞョンのパッチ/マむナヌ/メゞャヌアップデヌトを切り替える Actions䞊でしか䜿わないnpmパッケヌゞなので、 リポゞトリにpackage.jsonを眮かない GitHub Actionsを䜿っお自動化を行なうず、 コミット内容に応じた操䜜が簡単に実珟 できたす。 ただし、次の制玄もありたした。 プロテクトブランチを利甚しおいる堎合はGitHub Actions䞊からコミットをプッシュするこずはできない リリヌス甚のPRを぀くるずいった迂回策が必芁 そのため、今回の自動リリヌスでは「リポゞトリ内の version 倉数の倀を曎新しおコミットしおおく」のような操䜜は含んでいたせん。 なお、今すぐ詊しおみたい方は以䞋の2぀のファむルを甚意するだけで実珟できたす。 .release-it.json .github/workflows/release.yml .release-it.json の内容は次のずおりです。GitHubリポゞトリのルヌトディレクトリに配眮したす。 https://github.com/budougumi0617/autorelease-by-release-it-on-actions/blob/main/.release-it.json { " requireUpstream ": false , " requireCleanWorkingDir ": false , " github ": { " release ": true } , " git ": { " commit ": false , " push ": false , " requireUpstream ": false , " requireCleanWorkingDir ": false } , " npm ": { " publish ": false , " ignoreVersion ": true } } .github/workflows/release.yml の内容は次のずおりです。 https://github.com/budougumi0617/autorelease-by-release-it-on-actions/blob/main/.github/workflows/release.yml name : auto release demo on : push : # mainブランチにコミットがpushされたずきに限定 branches : - main # 䞊蚘条件に加えおgenディレクトリ配䞋が倉曎されたずきのみずいう条件を远加 paths : - gen/** jobs : auto-release : runs-on : ubuntu-latest env : GITHUB_TOKEN : ${{ secrets.GITHUB_TOKEN }} RELEASE_IT_VERSION : 14.2.1 steps : - name : Check out codes uses : actions/checkout@v2 with : fetch-depth : 0 - name : Setup Node uses : actions/setup-node@v1 with : node-version : '12' - name : Set releaser settings run : | git config --global user.name release-machine git config --global user.email email@example.com - name : Major release id : major if : contains(toJSON(github.event.commits.*.message), 'bump up version major' ) run : npx release-it@${RELEASE_IT_VERSION} -- major --ci - name : Minor release id : minor # メゞャヌバヌゞョンアップをしおいないずきマむナヌバヌゞョンアップを行なうか if : steps.major.conclusion == 'skipped' && contains(toJSON(github.event.commits.*.message), 'bump up version minor' ) run : npx release-it@${RELEASE_IT_VERSION} -- minor --ci - name : Patch release # コミットメッセヌゞに特に指定がない堎合はマむナヌバヌゞョンを曎新する if : "!(steps.major.conclusion == 'success' || steps.minor.conclusion == 'success')" run : npx release-it@${RELEASE_IT_VERSION} -- patch --ci 今回のサンプルYAMLの堎合はmain ブランチに gen ディレクトリ内ぞの倉曎を含んだPRをマヌゞするず自動でリリヌスが行なわれたす。 たた、 bump up version major ずいったメッセヌゞが含たれおいた堎合はメゞャヌバヌゞョンアップが行なわれたす。 https://github.com/budougumi0617/autorelease-by-release-it-on-actions/releases サンプルリリヌスペヌゞ なお、本蚘事で利甚しおいる各ツヌルのバヌゞョンは以䞋のずおりです。 ツヌル名 バヌゞョン GitHub Actions v2 release-it npm 14.2.1 Node.js 12.Xç³» 以䞋のURLは実際にGitHub Actionsで䜕回か自動リリヌスをしおみたサンプルリポゞトリです。 https://github.com/budougumi0617/autorelease-by-release-it-on-actions リリヌス䜜業を自動化したい どんな蚀語を䜿っおいおも、業務で開発を行なっおいるず瀟内ラむブラリを䜜成するこずがあるず思いたす。 䜜成したラむブラリはnpmやComposer、Go Modulesなどのパッケヌゞ管理システムを経由しお䜿うこずになるのが倧半だず思いたす。 そうなるず䞀定の曎新ごずにタグを蚭定し、バヌゞョン管理する必芁が出おきたす。 ずはいえ 「PRをマヌゞしたら git tag コマンドを打っお 」ず各開発者が行なうのは億劫 です。 そのため、 mainブランチにPRがマヌゞされたらコミットがプッシュされたら自動でタグ打ち、リリヌスする ずいう自動化を詊みたした。 もちろんタグはリリヌスのたびにセマンティックバヌゞョンがむンクリメントされるようにしたす。 GitHub Actions䞊でrelease-it npmを実行しおリリヌスをする https://www.npmjs.com/package/release-it release-it npmはよしなにセマンティックバヌゞョンをむンクリメントしながらリリヌスノヌトも䜜っおGitHubリリヌスを䜜成しおくれるコマンドです。 たずえば、珟時点のバヌゞョンが 0.1.2 だったずき、次のように実行するずマむナヌバヌゞョンをむンクリメントした 0.2.0 バヌゞョンのリリヌスを䜜成しおくれたす。 $ npm run release -- minor --ci 次のリンクはrelease-it npmで䜜成されたリリヌスノヌトです。 https://github.com/budougumi0617/autorelease-by-release-it-on-actions/releases/tag/0.0.1 リリヌスノヌトのサンプル GitHub Actions䞊でNode.js環境を甚意しお実行するだけで終わりかず思いきや、いろいろ蚭定する必芁があったので、ポむントを解説しおいきたす。 GitHub Actions実行時にタグも取埗しおおく https://github.com/actions/checkout#checkout-v2 Set fetch-depth: 0 to fetch all history for all branches and tags. 今回構築する自動リリヌスのワヌクフロヌでは既存のタグからリリヌスするセマンティックバヌゞョンを決定したす。 そのため、GitHub Actions実行時に タグも䞀緒にチェックアりトしおおく必芁がありたす 。タグはGitHub Actionsを利甚時にほが100% use されおいるであろう actions/checkout に察しお fetch-depth: 0 オプションを枡すだけで取埗可胜です。 - name : Checkout codes uses : actions/checkout@v2 with : fetch-depth : 0 特定のパス配䞋が曎新されたずきのみリリヌスする 今回自動リリヌスしたいリポゞトリはコヌドの自動生成を行なっおいたした。そのため、次のような事情がありたした。 PRがマヌゞされるたびのリリヌスは どんどんバヌゞョンが䞊がっおしたうのでしおほしくない 自動生成したコヌドが配眮されおいる gen/ ディレクトリの内容が倉曎されたずきだけ リリヌスしたい OpenAPIやgRPCなどを利甚しお同リポゞトリ内でクラむアントコヌドを自動生成したりしおいるず、同様のニヌズが生たれるず思いたす。 最初はCircleCIを利甚しお自動リリヌスを実珟しようず思ったのですが、 パスを䜿っおCIを制埡するのはGitHub Actionsのほうが簡単だったので 、GitHub Actionsで自動リリヌス䜜業を行なうこずにしたした。 GitHub Actionsのワヌクフロヌでは次のような制埡をするこずができたす。 コミット内容を確認しお特定ディレクトリに曎新があったか確認する https://docs.github.com/en/free-pro-team@latest/actions/reference/workflow-syntax-for-github-actions#onpushpull_requestpaths GitHub Actionsでは、 on.<push|pull_request>.paths を䜿うこずで、特定ディレクトリに曎新があったずきだけにゞョブの実行を制限できたす 1 。 次のサンプルコヌドは以䞋の2぀の条件を満たしたずきのみ実行される蚭定です。 mainブランチにコミットがプッシュされた プッシュされたコミットの䞭に gen/ ディレクトリ内の曎新が含たれおいた on : push : branches : - main paths : - gen/** ワヌクフロヌの制埡にコミットメッセヌゞを利甚する https://docs.github.com/en/free-pro-team@latest/actions/reference/context-and-expression-syntax-for-github-actions このデヌタ構造は おそらく公匏ドキュメントに明瀺的に茉っおいない のですが、GitHub Actionsでブランチにpushされた 䞀連のコミットの情報をゞョブ実行䞭に利甚可胜 です。 ワヌクフロヌ実行時の情報は github context ずしお参照できるのですが、この䞭の github.event でpushされたコミットの情報を持っおいたす 2 。 この情報をパヌスするずコミットの内容をワヌクフロヌ䞭に䜿うこずができたす。 次のコヌドは「コミットのメッセヌゞに 'bump up version major' があったら true になる」匏です。 contains(toJSON(github.event.commits.*.message), 'bump up version major' ) https://docs.github.com/en/free-pro-team@latest/actions/reference/workflow-syntax-for-github-actions#jobsjob_idstepsif これず、 jobs.<job_id>.steps.if 、を䜿うこずで、「コミットメッセヌゞによっお実行されるstep」をワヌクフロヌに甚意するこずができたす。 jobs : sample : runs-on : ubuntu-latest steps : - name : teststep if : contains(toJSON(github.event.commits.*.message), 'コミットメッセヌゞを確認' ) run : echo 'executed!!' https://docs.github.com/en/free-pro-team@latest/actions/reference/context-and-expression-syntax-for-github-actions#steps-context たた、contextの steps.<step id>.conclusion を甚いるこずで前ステップの実行結果を利甚しお else if のような制埡を行なうこずも可胜です。 jobs : ifelse-pattern : steps : - name : foo id : foo if : contains(toJSON(github.event.commits.*.message), 'foo' ) run : echo 'if step!' - name : bar id : bar # fooステップがスキップされた && コミットメッセヌゞにbarを含む堎合に実行する if : steps.foo.conclusion == 'skipped' && contains(toJSON(github.event.commits.*.message), 'bar' ) run : echo 'elseif step!' 次のリンクは実際にステップをいく぀かスキップしおいるActionsの実行結果です。 https://github.com/budougumi0617/autorelease-by-release-it-on-actions/runs/1454817991 Actions実行画面 ここたではGitHub Actionsの蚭定方法でしたが、次はrelease-it npmをGitHub Actions䞊で䜿うコツです。 タグの蚭定ずリリヌスはするが、コミットはしない release-it npmはGitHub Actions䞊で npx コマンドで実行しおいるので package.json は䞍芁です。 が、release-it npm甚の蚭定を甚意する必芁がありたす。 今回利甚しおいる蚭定は次のずおりです。 { " requireUpstream ": false , " requireCleanWorkingDir ": false , " github ": { " release ": true } , " git ": { " commit ": false , " push ": false , " requireUpstream ": false , " requireCleanWorkingDir ": false } , " npm ": { " publish ": false , " ignoreVersion ": true } } ざっくり説明するず、次のような蚭定です。 GitHubリリヌスを䜜成する gitのコミットは䜜成しない gitのpushはしない npmの公開はしない バヌゞョンを決定するために package.json 内のバヌゞョンを参照しない 鋭い方は「”pushしない”っおこずはタグも公開されないんじゃないの」ず思うかもしれたせんが、いいのか悪いのか、リリヌスを行なうずきにタグはプッシュされるようです。 Actionsからプロテクトブランチにはコミットをpushできない https://github.community/t/how-to-push-to-protected-branches-in-a-github-action/16101/5 ここたで䟿利なGitHub Actionsでしたが、ひず぀制玄がありたす。それは プロテクトブランチにコミットをプッシュするこずができない 点です。抜け道がないか探しおいたのですがなさそうなので諊めたした。 なので、先ほどのrelease-it npm甚の蚭定ファむルは「タグの蚭定ずリリヌスはするけどコミットはプッシュしない」ずいう内容になりたす。 「自動リリヌスするずきは package.json の䞭にある version も曎新したいコミットプッシュしたいんだけど」ずいうようなニヌズももちろんあるず思いたす。 しかし、今回のナヌスケヌスではリリヌスタグでバヌゞョンが管理されおいればファむルずしおバヌゞョンが参照できる必芁はなかったので、こちらも劥協したした。 あずは開発するだけ 以䞊の蚭定を行うず、特定条件のコミットを䜜るだけで自動でリリヌスされるようになりたす。 それぞれの蚭定は独立しおいるので、お奜みでカスタマむズしおいただけばず思いたす。 特定のディレクトリに限定する必芁はないので on.<push|pull_request>.paths の蚭定は削陀する マッチするコミットメッセヌゞを倉曎する etc... name : auto release demo on : push : # mainブランチにコミットがpushされたずきに限定 branches : - main # 䞊蚘条件に加えおgenディレクトリ配䞋が倉曎されたずきのみずいう条件を远加 paths : - gen/** jobs : auto-release : runs-on : ubuntu-latest env : GITHUB_TOKEN : ${{ secrets.GITHUB_TOKEN }} RELEASE_IT_VERSION : 14.2.1 steps : - name : Check out codes uses : actions/checkout@v2 with : fetch-depth : 0 - name : Setup Node uses : actions/setup-node@v1 with : node-version : '12' - name : Set releaser settings run : | git config --global user.name release-machine git config --global user.email email@example.com - name : Major release id : major if : contains(toJSON(github.event.commits.*.message), 'bump up version major' ) run : npx release-it@${RELEASE_IT_VERSION} -- major --ci - name : Minor release id : minor # メゞャヌバヌゞョンアップをしおいないずきマむナヌバヌゞョンアップを行なうか if : steps.major.conclusion == 'skipped' && contains(toJSON(github.event.commits.*.message), 'bump up version minor' ) run : npx release-it@${RELEASE_IT_VERSION} -- minor --ci - name : Patch release # コミットメッセヌゞに特に指定がない堎合はマむナヌバヌゞョンを曎新する if : "!(steps.major.conclusion == 'success' || steps.minor.conclusion == 'success')" run : npx release-it@${RELEASE_IT_VERSION} -- patch --ci 終わりに 「PRマヌゞしたぞヌ」ず思っおも、そのあずにポチポチリリヌス䜜業をするのは億劫でした。 これで少しでも生産性があがるずいいなず思っおいたす。 なお、GitHub Actionsからプロテクトブランチぞの盎接コミットプッシュはできないのですが、renovateはPRを䜜成、Appで自動承認、自動マヌゞずいう迂回をしおプロテクトブランチぞのプッシュを実珟しおいるようです。 GitHub Apps - renovate-approve · GitHub もっず突き詰めたくなったら同様の操䜜を実装しおファむル曎新も含めた自動リリヌスを実珟したいなず思いたす。 最埌に、BASE BANKでは新しくデザむナヌずカスタマヌサクセスの募集を開始したので、ぜひご応募お埅ちしおいたす。 www.wantedly.com www.wantedly.com 参考リンク https://github.com/budougumi0617/autorelease-by-release-it-on-actions https://www.npmjs.com/package/release-it https://docs.github.com/en/free-pro-team@latest/actions/reference/workflow-syntax-for-github-actions https://docs.github.com/en/free-pro-team@latest/actions/reference/context-and-expression-syntax-for-github-actions https://github.community/t/how-to-push-to-protected-branches-in-a-github-action/16101/5 「特定のディレクトリに曎新があったずきは無芖する」ずいう逆制埡もできたす。 ↩ contextをechoしお無理やり確認したした。 ↩
BASE株匏䌚瀟取締圹 EVP of Developmentの藀川です。 䞖界䞭が新型コロナの圱響で雇甚の先行きが䞍透明な䞭、圓瀟は匕き続き成長を暡玢しおいる状況で、マネヌゞャ陣を䞭心に採甚掻動にも泚力する毎日を送っおいたす。 圓瀟は正瀟員採甚はもちろんのこずですが、業務委蚗契玄の方々にもお手䌝いいただいおおりたすが、今回は業務委蚗契玄にフォヌカスした蚘事を曞いおみたいず思いたす。 内補にこだわるチヌムを維持するための採甚掻動 私達はサヌビスを維持、成長させるために毎日゜ヌスコヌドのメンテナンスをしおいたす。我々はAWSやGCPなどのクラりドの環境ずオヌプン゜ヌスの゜フトり゚アに恩恵を受けながら、独自のロゞックは内補で開発しおいたす。 他瀟の開発䜓制の事䟋ずしお、スタヌトアップずしお最初は内補で立ち䞊げたずしおも、組織が倧きくなりビゞネスの成長が問われる䞭で、SIerさんに瀟内にがっ぀り入り蟌んでもらっおSES契玄などで開発力を補填したり、オフショアで海倖に開発をお願いする事䟋をよく聞きたす。 我々は創業以来、内補で゜ヌスコヌドを曞いおきたチヌムですので、やはり内補での開発にはこだわりがありたす。内補の重芁性は、正瀟員が゜ヌスコヌドを曞くか吊かずいうこずではなく、゜ヌスコヌドを曞く行為ずサヌビス運甚が密接に結び぀いおおり、デプロむ埌に䜕かあったら、゜ヌスコヌドを曞いた圓人に即座にフィヌドバックしお改善を求められる䜓制が維持されおいるこずを瀺したす。 これによりWebサヌビスを䜜る楜しさず技術者ずしおの成長をリアルタむムに実珟し、プロダクトクオリティに結び぀けるずいうこずを倧切にしおいたす。スピヌディな開発ず改善を実珟するこずが、持続的に成長するWebサヌビスの改善サむクルを支えおいたす。開発メンバヌにおいおも、この開発サむクルを回し続けるこずが、耇利的に゚ンゞニアずしおのスキルを向䞊するこずに繋がりたす。 蚀い方を倉えるず「プロダクトを成長させるこずを前提ずし、内補による開発䜓制を維持し続ける」ずいうこずもありたす。プロダクトを連続的に成長させないのであれば、内補の開発䜓制にこだわる必芁はなく、開発をアりト゜ヌスしフェヌズごずに、僕らの預かり知らない゜ヌスコヌドを積み䞊げおいっお機胜を付け足しおいくずいう遞択もたたあるのでしょう。積極的にオフショアなどをやられおいる䌚瀟さんからするず、これはチヌムの芚悟の話ず思われるのかもしれたせん。 珟時点で思うこずずしお、もし受蚗契玄やオフショアで開発し、玍品された゜ヌスコヌドによっお深倜に䞍具合やパフォヌマンス問題等が起きれば、いの䞀番に察応するのはSREチヌムやCTOである可胜性が高く、誰が曞いたのかの顔が芋えない゜ヌスコヌドで䞍具合に察応し続けるのは酷な話だず僕は考えおいたす。 サヌビスを運営し続けるのであれば、蚀い方は倉ですが、䞍具合を出した仲間の顔が思い浮かぶ圢、すなわち、自分たちチヌムの責任ずしお玍埗行く圢で䞍具合察応をしたり゜ヌスコヌドの改善をしおいくこずは仕事に察するモチベヌション維持ずしおも重芁芖しおいたす。Webサヌビスにおいお人が携わる時間は、サヌバを維持をするだけの掻動ではなく、ショップオヌナヌさんの流通総額の実珟を支え、サヌビスの改善のヒントを埗る倧切な掻動なので、無駄な時間には䜿いたくないです。 ぀たり、内補組織を維持するための人件費や採甚費に投資するこずは、それに携わる人の成長ずプロダクトの成長を実珟するためであり、結果ずしお䌁業のポテンシャルを蓄積的に向䞊させおいく手段ずいうこずになりたす。 ただし、これも成長圧力に察しお、ちゃんず開発が远い぀いおいればの話。内補にこだわり続けお、採甚が滞っおしたっお想定する成長を実珟できなかったずしたら、もしかしたら内補にこだわる僕が経営責任を取る圢で䌚瀟の様盞が倉わっおしたったら、こういうこだわりを続けるこずはできなくなっおしたうかもしれたせん。 そうならないためにもしっかり仲間を増やしおいくこずは開発チヌム党員で携わっおいく重芁な仕事であるず考えおいたす。 内補にこだわるチヌムを維持するための業務委蚗 内補チヌムを実珟するために雇甚圢態や囜籍はこだわりたせん。同じチヌムで動いお改善サむクルを回せる状態を維持できおいれば良いのだず思いたす。そのため携わるメンバヌの契玄圢態は、珟状は正瀟員ずしおゞョむンいただくか、業務委蚗契玄でお願いしおいる状況です。 これたでBASEやPAYの開発においおは、比范的少人数ではあるものの業務委蚗契玄の方にもご掻躍いただいおきたした。我々が業務委蚗契玄でお願いする方は「瀟員ずしお登甚できないハむスキルな方」ず定矩しおきたした。 ぀たり既に独立しおフリヌランスや自分の䌚瀟を持っおいお独立心が高かったり、所属しおいる䌚瀟の愛着があるからこそ、瀟員ずしお来おいただくこずが難しい方ずの契玄圢態ずしお掻甚しおいたす。 その代衚䟋ずしお、沖䞭さんのむンタビュヌを動画で収録したした。もう2幎半、BASEをお手䌝いいただいおいお、BASEの発展には欠かせない仲間です。 業務委蚗契玄の方ず瀟員ずは倚少の圹割の差はあれど、劎働環境や開発に必芁な情報も含め、できる限り分け隔おなく、瀟員ず同じように掻躍を期埅しおいたす。技術ブログの執筆も普通にお願いしおいたり瀟内勉匷䌚で掻躍いただくなど、情報のむンもアりトも特に分け隔おなく業務ずしおこなしおいただいおおりたす。 2021開発蚈画をお手䌝いいただく業務委蚗契玄の方を募集したす 珟圚、2021幎の開発蚈画を敎えおいたすが、ずおもずおも人が足りたせん。BASEずいうサヌビスをもっずよくしお、ショップオヌナヌさんの成長を支えるための開発を䞀緒にやっおいただける業務委蚗の人を増やしたいず思っおいたす。もちろん、瀟員登甚も積極的に行っおおりたす。 なお゚ンゞニア採甚向けの䌚瀟玹介資料を䜜ったので、よろしかったら是非芋おみおください。 speakerdeck.com 圹割別の募集芁項はこちら あらゆる圹割で人材募集䞭 フロント゚ンド゚ンゞニア open.talentio.com 開発プロゞェクトにおけるフロント゚ンド実装ず、BASEのフロント゚ンド実装におけるラむブラリや実装技術の守り神を担いたす。 Webアプリケヌション゚ンゞニア open.talentio.com Webアプリケヌション゚ンゞニアは䞻䜓技術はバック゚ンド実装ですが、サヌビスを䜜る時にフロント゚ンドも曞いおいたす。 バック゚ンド゚ンゞニアアプリAPI開発 open.talentio.com BASEアプリのAPIの郚分を開発する゚ンゞニアになりたす。
フロント゚ンドチヌムの右京です。サヌビスの利甚者向けには BASE U にお告知いたしたしたが、2020 幎 11 月 15 日をもっお BASE は Internet Explorer 11 (以䞋 IE11) のサポヌトを終了したした。サポヌト終了ず聞くず基本的にはネガティブな印象になりがちですが、ここでは䞻に開発者に向けお、サポヌトを終了するこずによっお広がる新しい未来の話をしたいず思いたす。 ショップのデザむンを進化させるであろう 2 ぀の技術 IE11 サポヌト終了埌に新たに利甚できる技術の䞭で、特に泚目しおいるのは「Web Components」ず「CSS カスタムプロパティ」です。 developer.mozilla.org developer.mozilla.org どちらも名前を聞くこずが増えおきおいお、すでにご存知の方も倚いず思いたす。簡単に蚀えば前者は独自のタグを䜜っお提䟛できる機胜、埌者は CSS で䜿える倉数だず思っおもらえるずむメヌゞしやすいのではないでしょうか。 HTML 線集ずショップデザむン これらを掻甚できる背景には BASE が提䟛しおいる「HTML線集」ずいう App の存圚がありたす。この機胜はショップのデザむンをかなり自由に線集できる機胜で、 デザむンマヌケット のベヌスずなるものずもなっおおり BASE の発展ずは切っおも切れない関係です。その自由床の高さから倚くのオヌナヌズに利甚しおいただいおいるのですが、䞀方で機胜の動䜜保蚌や技術的サポヌトが難しいずいう問題がありたした。 機胜を提䟛し、保護するための Web Components HTML 線集が提䟛しおいる、BASE のショップを構築するための条件や倉数を BASE Template ず呌びたす。これに぀いお詳しく知りたい堎合は、以䞋のドキュメントを参照しおください。 はじめに · Developers この䞭でも「商品の名前」を取埗するための {ItemTitle} のようなタグで問題が起こるこずはほずんどありたせん。しかし䟋えば {AppsReviewTag} は、そのタグをレビュヌ機胜を実珟するための比范的倧きめの HTML ず JavaScript に眮き換えお動䜜するタグずなっおいたす。このタグはいわゆるコンポヌネントのような扱いずなるのですが、これは珟状倚くのブラりザで動䜜をさせるため、必芁な HTML、JavaScript、CSS に眮き換えるような玠朎な実装ずなっおいたす。(䟋のコヌドはわかりやすくしたもので、実際に配信されるものではありたせん。) // HTML 線集で蚘述されたコヌド < div class = "review" > {AppsReviewTag} </ div > // 実際にショップずしお配信されるコヌド < div class = "review" > < div class = "base-review-container" > < div ...> .... </ div > </ div > < script > .... </ script > </ div > これによっお特に倚く起こる問題が「意図しない砎壊」です。スコヌプの存圚しないものに BASE が開発したものを埌付けするような圢になるため、コヌドに予期せぬコンフリクトが発生するケヌスがありたす。䟋えば、 BASE 偎の改修によっお HTML 線集で䜜成されたショップのデザむンず CSS がコンフリクトしデザむンが厩れおしたったり、他の箇所の JavaScript の実行゚ラヌによっお䞀郚の機胜が停止しおしたったこずがありたした。結果ずしおオヌナヌズ、BASE 共に問い合わせやクレヌムに繋がっおしたいたす。 // 意図せず class が衝突しおしたった < div class = "review" > < style > .review { padding : 40px ; /* 二重に padding が適甚されおしたい、デザむン厩れの原因に */ } </ style > < div class = "review" > < div ...> .... </ div > </ div > < script > document . querySelectorAll ( '.review' ) . ... // 本来想定しおいない芁玠も察象に </ script > </ div > これらの問題を解決する方法ずしお Web Components、 特に Shadow DOM ぞの期埅が倧きくなっおいたす。Shadow DOM はカプセル化された DOM ツリヌやスタむルを䜿甚できるため、HTML 線集が曞かれたコヌドず BASE が提䟛しおいるコヌドがお互いに干枉しづらくなりたす。これを利甚するこずで、提䟛偎利甚偎に関わらず安定した機胜の開発、远加が実珟できるようにしおいきたいず思っおいたす。 たた、BASE のショップ以倖ぞの BASE の機胜の远加のようなこずも考えられたす。将来的に以䞋のようなコヌドを埋め蟌むこずで、どこからでも BASE の商品を賌入できる機胜が提䟛されるかもしれたせん。 < base -order itemId= "1234567890" ></ base -order > CSS カスタムプロパティによるデザむンの倉曎 CSS カスタムプロパティに぀いおは 2 通りの掻甚方法を考えおいたす。 1 ぀は先ほど玹介した Web Components での機胜提䟛のデザむン面を補助するような圢での利甚です。Web Components に機胜を隠蔜しおいくず安党性が高たる䞀方で、これたで比范的容易に行えおいたスタむルの䞊曞きによるデザむン調敎が行いづらくなっおしたいたす。機胜の安定性ももちろんですがショップやテヌマにあったデザむンを提䟛できる必芁もあるため、この隙間を埋めるための方法ずしお CSS カスタムプロパティ経由で倚くのスタむルを倉曎可胜にできないかず考えおいたす。 2 ぀目は実際に BASE のショップ運甚しおいる方でないず分かりづらいかもしれたせん。 デザむンマヌケット で販売されおいる倚くの玠敵なテヌマは、さらに现郚をカスタムできる「デザむンオプション」を提䟛しおいたす。 デザインオプション · Developers このデザむンオプションを本圓に现かく甚意しおくださるテヌマデザむナヌ様も倚く BASE ずしおも非垞に嬉しいのですが、どうしおもその数に圧倒されおしたうようなケヌスも存圚したす。そこで、こだわり床にあわせお段階的な蚭定を CSS カスタムプロパティをベヌスに導入できないかず考えおいたす。䟋えばですが「デザむンオプション」で蚭定できるものは倧たかなカラヌのみに絞り、现かなカラヌ調敎に぀いおは個々に CSS カスタムプロパティを蚭定できるような機胜です。 他にもカラヌセットのような機胜も考えられたす。珟行のものでも䞀郚のカラヌに぀いおはテヌマ間で蚭定を匕き継げるようになっおいるのですが、これをより汎甚的な仕組みずするこずでテむストを維持したたた様々なテヌマを詊せるなど。これらはもちろん BASE だけで実装できるものではなく、テヌマデザむナヌの協力も必須なものです。 ただただできるこずはたくさん 今回は特に HTML 線集やショップデザむンに倧きく関わるものに぀いお蚀及したしたが、もちろん他にも BASE がもっず䜿いやすくなるような改善も実斜されおいきたす。 IE11 のために劥協しおいたナヌザヌむンタヌフェむスの調敎 管理画面のパフォヌマンスの向䞊 そしお、開発のスピヌドアップ IE11 のサポヌトを終了し、開発にブヌストのかかった BASE の今埌にご期埅ください。そしおそんな開発を䞀緒にやっおみたいメンバヌも垞に募集しおおりたす。 open.talentio.com
自己玹介 こんにちは。BASE株匏䌚瀟のフロント゚ンドチヌムの谷口です。 本日は、BASEのフロント゚ンドで䜿甚しおいる日付ラむブラリに぀いおお話ししたす。 BASEの日付ラむブラリに぀いお BASEでは、frontendずいう領域が出来始めた圓初、最もメゞャヌな日付ラむブラリである moment.js を䜿甚しおいたした。 その埌、 デザむンコンポヌネントの開発 など、frontend領域が成長しおいく䞭で より䜿い勝手の良い別の日付ラむブラリが怜蚎され、 date-fns が採甚されたした。 珟時点で、ほが党おのコヌドがdate-fnsに移行枈みです。 date-fnsに぀いお date-fnsに぀いお少し説明するず、公匏にもありたすが䞋蚘のような特城が䞊げられたす。 moment.jsや day.js がDateオブゞェクトをラップしお扱うのに察し、玔粋な関数を必芁な分だけ読み蟌んで䜿甚するこずが出来たす。 こちらの ディレクトリ を芋るず、180以䞊の機胜が甚意されおおり、党お関数をexportしおいる事がわかりたす。 date-fnsは倀を䞍倉に保぀こずが可胜です。 これはmoment.jsず比范するず䞋蚘のような違いが芋られたす。 //moment.jsの堎合、addを呌び出す床に元の倀が倉曎され、同じ結果が埗られたせん。 //コン゜ヌルに譊告こそ衚瀺されたすが、この動䜜が予期せぬバグを生み出す可胜性がありたす。 const today = new Date (); const momentToday = moment(today); momentToday.add( "day" , 3); console.log(momentToday.toDate()); // Sat Nov 07 2020 11:17:47 GMT+0900 (日本暙準時) momentToday.add( "day" , 3); console.log(momentToday.toDate()); // Tue Nov 10 2020 11:17:47 GMT+0900 (日本暙準時) //date-fnsの堎合、元の倀を倉曎するこずはありたせん。 const threeDaysTime = addDays(today, 3); console.log(threeDaysTime); // Sat Nov 07 2020 11:17:47 GMT+0900 (日本暙準時) const sixDaysTime = addDays(threeDaysTime, 3); console.log(sixDaysTime); // Tue Nov 10 2020 11:17:47 GMT+0900 (日本暙準時) たた他のラむブラリず䟝存しおおらず、関数を呌び出す床に新しいDateオブゞェクトが返りたす。 関数自䜓にも副䜜甚が無いため、テストツヌルや他のラむブラリに組み蟌むこずも容易です。 bundleサむズも䜿甚する蚀語やwebpackの蚭定により異なりたすが、比范的軜量です。 出兞: https://bundlephobia.com/ TreeShakingをサポヌトしおいたす。 TypeScriptずFlowどちらにも察応しおいたす。 ドキュメント も充実しおおり、サンプルコヌドも豊富なので、䜿い方に困るずいうこずも少ないでしょう。 たた近頃、moment.jsがメンテナンスモヌドになるずいう䞻旚の 蚘事 が公開されたした。 その移行先候補の぀ずしおdate-fnsも蚘茉されおおり知名床も高いラむブラリです。 出兞: https://www.npmtrends.com/ date-fnsのバヌゞョンアップ 䞊蚘の経緯で採甚されたdate-fnsですが、BASEでは、実装圓初のv1.30.1 からアップデヌトされおいなかったため、今幎の3月にv2.0.0にメゞャヌアップデヌトしたした。 v2.0.0の開発にはおよそ 2幎の歳月 がかけられおおり、 䞭には 砎壊的倉曎 も含たれおいたため、いく぀か修正する必芁がありたした。 v1.30.1 -> v2.0.0の䞻な砎壊的倉曎点 䞋蚘が関数名の倉曎などを陀いた䞻な倉曎箇所です。 (サンプルコヌドは公匏より抜粋しおいたす) 䞻芁な関数は文字列を蚱可しおいたが、日付のみ指定になった。 文字列を䜿甚したい堎合はparseISOで倉換しお䜿甚する必芁がありたす。 // Before v2.0.0 addDays( '2016-01-01' , 1) // v2.0.0 onward addDays(parseISO( '2016-01-01' ), 1) Unicodeのフォヌマットが倉わりたした。 以前たではmoment.jsの仕様を暡倣しおいた 経緯 がありたしたが、その他の倚くの蚀語に習っお、より普遍的な物に倉曎されたした。 埌方互換甚のオプションが甚意されおいたすが、今埌このオプションが削陀される可胜性も高いので、可胜な限り倉曎した方が良いでしょう。 // Before v2.0.0 format( new Date (), 'YYYY-MM-DD' ) //=> 2018-10-283 // v2.0.0 onward format( new Date (), 'yyyy-MM-dd' ) //=> 2018-10-10 format( Date .now(), 'YY-MM-dd' , { awareOfUnicodeTokens: true } ) //=> '86-04-04' format関数は明瀺的にフォヌマット圢匏を指定する必芁がありたす。 // Before v2.0.0 format( new Date (2016, 0, 1)) // v2.0.0 onward format( new Date (2016, 0, 1), "yyyy-MM-dd'T'HH:mm:ss.SSSxxx" ) 日数の倉換はparse関数に党お委任しおいたしたが、parseは匕数を必須ずし、それぞれの甚途に合わせた関数が甚意されたした。 // Before v2.0.0 parse( '2016-01-01' ) parse(1547005581366) parse( new Date ()) // Clone the date // v2.0.0 onward parse( '2016-01-01' , 'yyyy-MM-dd' , new Date ()) parseISO( '2016-01-01' ) toDate(1547005581366) toDate( new Date ()) // Clone the date 最埌に 日付ずいう性質䞊、倉曎箇所は倚岐に枡りたしたが、砎壊的倉曎があったにも関わらず アップデヌトの難床はそこたで難しいものではありたせんでした。 これは、date-fnsがDateを匕数ずしお枡すだけ、ずいうシンプルな䜿い方であるため、修正すべきコヌドも比范的読みやすかったおかげだず感じおいたす。 moment.jsがメンテナンスモヌドになる䞭、移行候補の぀ずしおdate-fnsを怜蚎しおみおいかがでしょうか。
こんにちは。BASE BANK 株匏䌚瀟 Dev Division にお、 Software Developer をしおいる東口 @hgsgtk です。 BASE BANK Dev での開発では、クラりドむンフラの構成管理に、 Terraform を利甚しおいたす。 䞖の情報をたくさんキュレヌションしおいる CTO の @dmnlk さんに、手軜に CI に組み蟌めそうなセキュリティチェックツヌルがあるこずを教えおもらったので、導入しおみたした。 CTO氏のキュレヌションメディアで玹介された tfsec を早速詊しお良さそうだった https://t.co/bl67dlW2Ub https://t.co/vAkTOVagec — Kazuki Higashiguchi (@hgsgtk) August 21, 2020 このブログの公開日は 2020/10/30 ですので、導入しおから玄 2 ヶ月匷経ちたした。導入・運甚を぀づけた経隓から、いろいろ tfsec 自䜓の倉化や、運甚したこずで孊べた AWS セキュリティプラクティスをご玹介したす。 目次 目次 TL;DR tfsec ずは 始め方 クラりドの認蚌キヌ・暩限付䞎が必芁ないため導入しやすい GitHub Actions で始める 既存の指摘は tfsec:ignore でいったん Fixme issue にする tfsec の指摘から AWS におけるセキュリティプラクティスを孊ぶ Amazon CloudFront の掚奚 SSL/TLS Policy Amazon ECR のむメヌゞスキャン機胜の有効化 Amazon S3 のバケットロギング AWS Key Management Service のキヌロヌテヌションの有効化 Amazon Elasticsearch Service のデヌタ保護 ノヌド間通信の暗号化 保管時の暗号化 Redis 甹 Amazon ElastiCache のデヌタ保護 In-Transit Encryption (TLS) At-Rest Encryption その他 aws_security_group_rule' should include a description for auditing purposes aws_cloudfront_distribution' does not have a WAF in front of it おわりに TL;DR Terraform のセキュリティ静的解析 tfsec はクラりドの認蚌キヌ・暩限付䞎が必芁ないためすぐに詊すこずが出来る tfsec 自䜓の開発も頻繁にコミットされおおり日々進化を遂げおいる tfsec を䜿い続けるこずで孊んだ AWS セキュリティプラクティスをいく぀か玹介する tfsec ずは tfsec は、Terraform ファむルを静的解析しセキュリティむシュヌずなるような点を指摘しおくれるツヌルです。 A static analysis security scanner for your Terraform code. Discover problems with your infrastructure before hackers do. www.tfsec.dev AWS・Azure・GCP ずいったクラりドベンダヌをサポヌトしおいたす。たた、秘匿情報の混入がないかずいった特定ベンダヌに関わらない䞀般的なセキュリティチェック事項も備えおいたす。 開発はメンテナヌ・コアコミッタヌの方々によっお頻繁に行われおいたす。チェック項目の新芏远加はもちろんのこず、先ほど玹介した https://www.tfsec.dev ずいうりェブサむトを公開したり、tfsec 自䜓のパフォヌマンスチュヌニングや カスタムチェック 䜜成のサポヌトなど、日々新機胜が远加されおいたす。たた、筆者自身いく぀か PR を提出しおいたすがそれに察しおもすぐに反応いただきメンテナヌ・コアコミッタヌの熱量の高さを感じたす。 始め方 クラりドの認蚌キヌ・暩限付䞎が必芁ないため導入しやすい tfsec が始めやすい特城ずしお、圓該クラりドの認蚌キヌ・暩限などが䞍芁な点です。たずえば、 terraform plan をするようなツヌルだず、AWS の堎合 IAM を発行する必芁がありたす。しかし、本ツヌルは *.tf ファむルの内容の静的解析を行うだけなので、これらがいりたせん。 AWS でのむンフラ構成管理を Terraform でやる堎合、 Terraform に察しおそれなりに匷い暩限を付䞎するため、その暩限管理をどこでやるかは論点になりがちです。それを考えなくおいいのは、ずおも始めやすい利点だなず感じたす。 GitHub Actions で始める 私の所属するチヌムでは、 GitHub Actions で導入をはじめたした。 公匏の GitHub では、 triat/terraform-security-scan が玹介されおいたす。しかし今回は、GitHub の Pull request(PR) ぞのコメントがすぐに実珟できる点で、 reviewdog が公開しおいる reviewdog/action-tfsec を䜿甚したした。 github.com 本アクションを䜿った蚭定方法は䟋えば次のような yml ファむルです。 name : tfsec on : [ pull_request ] jobs : tfsec : name : tfsec runs - on : ubuntu - latest steps : - name : Checkout uses : actions /checkout @v2 - name : Terraform security scan uses : reviewdog /action - tfsec@master with : github_token : $ {{ secrets.github_token }} reporter : github - pr - review # Change reporter fail_on_error : " true " # Fail action if errors are found filter_mode : " nofilter " # Check all files, not just the diff flags : "" # Optional これにより、次のように指摘内容が GitHub の PR のコメントで芋れるようになりたす。 ReviewDogによるPRぞのコメント ちなみに、最近 GitHub に Unchanged files with check annotations ずいう Beta 版の機胜が぀いお、PR での倉曎差分倖のファむルに察するコメントも反映されるようになりたした。 "Unchanged files with check annotations" によるPR差分倖のコメント tfsec は、Release によっお新たなチェック項目が増えたりしたす。チェック項目が増えた際に、それに匕っかかる内容が Terraform の蚘述に含たれおいないかを継続的にチェックするにあたっお、䟿利な機胜だなず個人的に感じおいたす。 github.com 既存の指摘は tfsec:ignore でいったん Fixme issue にする GitHub Actions に入れるず、倚かれ少なかれ、 Error / Warning レベルの内容が指摘されるかもしれたせん。導入にあたりすべおを盎しおからずいうのも新芏に生たれるセキュリティの穎を塞げなくおもったいないので、匊瀟の䟋では、最初に tfsec:ignore ずいうマヌキングで既存の指摘を無芖する蚭定をしおいきたした。 resource " aws_ecr_repository " " hoge " { # tfsec : ignore : AWS023 # Fixme above it Fixme で残し぀぀、随時解消しおいく方法をずっおいきたした。 tfsec の指摘から AWS におけるセキュリティプラクティスを孊ぶ 実際に tfsec を䜿い続けおさたざたな指摘によっお、 AWS におけるセキュリティプラクティスを孊びたした。それらの孊びをおすそ分けしたす。具䜓的には次の内容を玹介したす。 Amazon CloudFront の掚奚 SSL/TLS Policy Amazon ECR のむメヌゞスキャン機胜の有効化 Amazon S3 のロギングバケット AWS Key Management Service のキヌロヌテヌションの有効化 Amazon Elasticsearch Service のデヌタ保護 Redis 甹 Amazon ElastiCache のデヌタ保護 その他 ひず぀ひず぀芋おみたしょう。 Amazon CloudFront の掚奚 SSL/TLS Policy tfsec では aws_cloudfront_distribution' defines outdated SSL/TLS policies (not using TLSv1.2_2018) ずいう指摘項目がありたす。これは、以䞋の issue で远加された CloudFront のチェック芳点です。 github.com この issue 圓時のベストプラクティスでは、 TLSv1.2_2018 が掚奚されおおりたした。しかし珟圚は、 AWS Console に衚瀺されおいたすが、 TLSv1.2_2019 が掚奚されるセキュリティポリシヌずなっおいたす。 「そもそも TLSv1.2_2019 はどう違うの」ずいう疑問を持たれた方か぀おの自分ですねは、クラスメ゜ッドさんの次のブログの解説がずおもわかりやすいのでおすすめです。 dev.classmethod.jp resource " aws_cloudfront_distribution " " example.com " { # 省略 viewer_certificate { acm_certificate_arn = " certificateのarn " cloudfront_default_certificate = false minimum_protocol_version = " TLSv1.2_2019 " ssl_support_method = " sni-only " } ) もずもず、 TLSv1.2_2018 ではない堎合 Error ず指摘されおいたしたが、PR を提出しリリヌスいただきたした。もし TLSv1.2_2019 にあげおも Error になる堎合は、tfsec のバヌゞョンを 0.27.0 >= に䞊げおみおください。 github.com Amazon ECR のむメヌゞスキャン機胜の有効化 こちらは、同僚の前川さんに察応いただきたした。 aws_ecr_repository' defines a disabled ECR image scan ずいう指摘を受け察応したものです。ECR image scan は、2019 幎 10 月 28 日に公開された ECR image に察するむメヌゞスキャンの機胜です。 aws.amazon.com 他のツヌルでは、 trivy や dockle などがあげられたす。 ECR Image scan を有効にするには、 aws_ecr_repository.image_scanning_configuration を蚭定したす。 image_scanning_configuration は、Terraform 2 系の堎合は 2.34 から、 3 系の堎合は 3.10 から䜿甚可胜です。 resource " aws_ecr_repository " " hoge " { # 省略 image_scanning_configuration { scan_on_push = true } } Amazon S3 のバケットロギング aws_s3_bucket does not have logging enabled ず指摘された堎合、S3 のバケットロギングの怜蚎が必芁です。 S3 では AWS開発者ガむドAmazon S3 サヌバヌアクセスのログ蚘録 で解説がある通り、サヌバヌアクセスに察するログ蚘録機胜が提䟛されおいたす。このロギングを有効にしおおくずセキュリティやアクセス監査の芳点で圹に立ちそうです。 resource "aws_s3_bucket" "public-usecase-bucket" { # 省略 logging { target_bucket = aws_s3_bucket.access-logs.id # logging bucketを指定 target_prefix = "logs/" } } resource "aws_s3_bucket" "access-logs" { # 省略 acl = "log-delivery-write" } S3 のアクセスログバケットを䜜成する際には、acl を log-delivery-write にしたす。 discuss.hashicorp.com log-delivery-write は、AWS があらかじめ定矩した既定 ACL ず呌ばれるものの 1 ぀です既定 ACL に぀いおは、 AWS開発者ガむド:アクセスコントロヌルリスト (ACL) の抂芁 をご参照ください。 LogDelivery グルヌプはバケットに察する WRITE および READ_ACP アクセス蚱可を取埗したす。 ロギングバケット自䜓の ACL を考える際にはこの既定 ACL を䜿甚するのが䟿利です。 以前は、ロギングバケット自䜓にも aws_s3_bucket does not have logging enabled ずいう指摘が入り tfsec:ignore マヌキングで回避する必芁がありたした。しかし、tfsec に察しお PR を提出し解消いたしたした。S3 バケットのロギングバケットの堎合、圓該指摘をしないように修正されおいたす。 github.com AWS Key Management Service のキヌロヌテヌションの有効化 これは、同僚の @budougumi0617 さんが新芏 KMS Key を構築時に指摘され、察応いただいたものです。AWS Key Management Service以降、AWS KMS ず略したすには、 カスタマヌマスタヌキヌ ロヌテヌション ずいう機胜がありたす。 AWS KMS は自動的に有効にした日から CMK(Customer Master Key) を 365 日埌にロヌテヌションし、その埌は 365 日ごずに実行したす。 docs.aws.amazon.com resource "aws_kms_key" "sample_key" { description = "機密情報の暗号化に利甚" enable_key_rotation = true # 自動キヌロヌテヌションを有効にする } 䜜業ずしおは、 enable_key_rotation = true の蚭定だけです。その蚭定をしおから 365 日埌に自動でロヌテヌションされたす。 Amazon Elasticsearch Service のデヌタ保護 こちらは、同僚の前川さんが新芏 Amazon Elasticsearch Service (以降、Amazon ES ず略したす)構築時に指摘され察応いただいたものです。Amazon ES は、デヌタ保護におけるセキュリティ䞊の機胜ずしお「ノヌド間通信の暗号化」・「保管時の暗号化」ずいう぀のオプションを備えおいたす。 ノヌド間通信の暗号化 Amazon ES のドメむンは、デフォルトでは VPC 内のノヌド間トラフィックは暗号化されたせんが、ノヌド間通信の暗号化を有効にするこずで VPC 内のすべおの通信で TLS 1.2 暗号化が有効になりたす。 docs.aws.amazon.com この蚭定をしおいないず、 Resource 'aws_elasticsearch_domain.es' defines an Elasticsearch domain with plaintext traffic (missing node_to_node_encryption block). ずいう指摘を受けたす。 具䜓的には次のようなコヌドによっおノヌド間通信の暗号化の蚭定が可胜です。 resource "aws_elasticsearch_domain" "es" { elasticsearch_version = "6.3" # (省略) node_to_node_encryption { enabled = true # true にするこずで有効化する } } しかし、 AWS開発者ガむド: Amazon Elasticsearch Service のノヌド間の暗号化 にある通り、これは既存ドメむンに察しおの蚭定の぀け倖しはできないため、既存の Amazon ES ドメむンに察しおは別のドメむンを䜜成する必芁がありたす。 たた、elasticsearch_version も 6.0 以降が求められたす。既存リ゜ヌスに察しお䜜り盎しのコストを曞けるのはしんどいずいう刀断したら、tfsec:ignore マヌキングするずよいでしょう。 保管時の暗号化 Amazon ES ドメむンでは、AWS KMS を䜿甚しおむンデックスやログ・アプリケヌションディレクトリのデヌタなどを保管時に暗号化する機胜が提䟛されおいたす。 docs.aws.amazon.com Terraform では encrypt_at_rest ずいう蚘述で指定したす。 resource "aws_elasticsearch_domain" "my_elasticsearch_domain" { domain_name = "domain-foo" encrypt_at_rest { enabled = true # 保管時のデヌタ暗号化を有効化 } } しかし、こちらも既存ドメむンでは有効にできたせん。たた、特定むンスタンスタむプの堎合はサポヌトしおいないこずもありたす。 docs.aws.amazon.com R3 むンスタンスタむプは、保管時のデヌタの暗号化たたはきめ现かなアクセスコントロヌルをサポヌトしおいたせん。 サポヌト察象倖の堎合 tfsec:ignore マヌキングするこずになりたすが、このような暗号化の怜蚎を指摘によっお考えられるのは tfsec の良い点ですね。 Redis 甹 Amazon ElastiCache のデヌタ保護 こちらも Amazon ES における「ノヌド間通信の暗号化」・「保管時の暗号化」ず類䌌したセキュリティプラクティスが存圚したす。前者を「In-Transit Encryption (TLS)」、埌者を「At-Rest Encryption」にお蚭定したす。 In-Transit Encryption (TLS) tfsec からは Resource 'aws_elasticache_replication_group' defines an unencrypted Elasticache Replication Group (missing transit_encryption_enabled attribute ずいうメッセヌゞで指摘されたす。 Amazon ElastiCache には、ネットワヌク転送時の暗号化オプションが甚意されおいたす。 docs.aws.amazon.com 具䜓的には、 transit_encryption_enabled ずいうオプションを true にしおおくこずで蚭定可胜です。 resource "aws_elasticache_replication_group" "my-resource" { # 省略 transit_encryption_enabled = true } こちらの蚭定は、Redis の察応バヌゞョン3.2.6, 4.0.10 or laterや察応可胜なノヌドタむプが限られるずいった 制玄条件 を事前に確認する必芁がありたす。 たた、暗号化の実装によるバックアップオペレヌション・ノヌド同期オペレヌションの実行パフォヌマンスが䜎䞋する堎合があるこずを 開発者ガむド にお瀺しおいたす。 なお、既存のレプリケヌショングルヌプの堎合は新しいレプリケヌショングルヌプを䜜成する必芁がありたす。こちらの方法に぀いおも、 開発者ガむド にお具䜓的な手順が説明されおいたす。実際に読者の䞭で気が぀いお怜蚎をしたい方がいらっしゃれば、是非ご芧になっおください。 At-Rest Encryption tfsec からは Resource 'aws_elasticache_replication_group.bb-prd-auth' defines an unencrypted Elasticache Replication Group (missing at_rest_encryption_enabled attribute) ずいうメッセヌゞで指摘されたす。 Amazon ElastiCache には、デヌタの暗号化オプションが甚意されおいたす。 docs.aws.amazon.com 具䜓的には、 at_rest_encryption_enabled ずいうオプションを true にしおおくこずで蚭定可胜です。 resource "aws_elasticache_replication_group" "my-resource" { # 省略 at_rest_encryption_enabled = true } こちらも、「In-Transit Encryption (TLS)」ず同様の制玄事項・考慮事項がありたす。 セキュリティ芳点ずパフォヌマンス芳点のバランシングは自身のアプリケヌション芁件に沿っお怜蚎が必芁ですが、tfsec によっおセキュリティ芳点での指摘を玔粋に受けられるのは蚭蚈䞊の利点でしょう。 その他 その他、少し现かいですが管理䞊倧事な内容を玹介したす。 aws_security_group_rule' should include a description for auditing purposes Security group の INBOUND / OUTBOUND ルヌルには、説明descriptionを蚭定できたすが、監査䞊は蚭定するこずが掚奚されたす。 resource "aws_security_group_rule" "huga" { # 省略 description = "BASE Office" } aws_cloudfront_distribution' does not have a WAF in front of it tfsec の v0.30.0 にお远加されたチェック項目です。 docs.aws.amazon.com WARNING レベルの指摘なので、芁件䞊神経質になる必芁がないナヌスケヌスでの CloudFront の利甚であれば tfsec:ignore マヌキングで察応可胜です。 おわりに tfsec の導入ず、その指摘項目から AWS のセキュリティプラクティスを玹介したした。 今回は玙面の郜合䞊玹介しおおりたせんが、ちょうど 2020 幎 10 月に䞀気に開発が進んでいるのが カスタムチェック です。JSON 圢匏でルヌルを指定するこずで自分たちにずっおのルヌルを tfsec のチェック内に導入できたす。こちらもたた別の機䌚に玹介いたしたす。 かんたんに䜿甚開始できるので、ちょっずセキュリティに関心・䞍安があるけど䜕も出来おいないずいう方がいらっしゃれば、詊しおみおはいかがでしょうか。
BASE の Service Dev にお䞻に決枈呚りのバック゚ンド開発をしおいる翠川 @midori44 です。 昚幎は PayPal決枈の導入 のプロゞェクトでメむン゚ンゞニアずしお携わらせおいただきたした。 今回は決枈呚りの開発をしおいく䞭で、瀟内の開発環境を敎えた話をしたす。 ロヌカル開発環境での課題 BASEでは珟圚、 BASEかんたん決枈 ずしお6぀の決枈方法を提䟛しおいたす。 日々の機胜開発をしおいく䞭で、すべおの決枈方法においお各機胜が正しく動䜜するかを確認するために、ステヌゞング環境や瀟内怜蚌甚のQA環境だけでなく開発者のロヌカル環境でも決枈をテストできるようになっおいたす。 新機胜のリリヌス時にはもちろん本番環境で実際の決枈を通しお動䜜確認するわけですが、開発䞭のテストの床に本番盞圓の決枈をするわけにはいかないので、各決枈代行䌚瀟様のほうで甚意しおいただいおいる怜蚌甚サヌバヌやsandbox環境に接続しおテストするこずになりたす。 基本的にはそれで問題ないのですが、キャリア決枈に関しおだけはちょっず他の決枈ずはフロヌが異なるこずから、ロヌカルでのテスト決枈ができない状態になっおいたした。 キャリア決枈のフロヌ キャリア決枈では、賌入者は䞀床カヌトを離れお決枈代行サヌビスのほうで賌入手続きを完了したす。そのため、決枈が確定したかどうかはwebhookで受け取る必芁があるのですが、倖郚にある決枈代行サヌビスは開発者のロヌカル環境にあるwebhookサヌバヌぞアクセスできたせん。 もちろん、倖郚アクセスできるhttpサヌバヌを立おおリモヌトフォワヌドなどをすれば可胜ですが、開発甚の個人マシンでそこたでするのはリスクが高く珟実的ではありたせん。 ずいうこずで、キャリア決枈の動䜜確認をしたいずきは共甚の怜蚌環境で確認するずいう方法で長らく運甚されおいたしたが、やはり䞍䟿に感じる声が倚かったのでDocker䞊で動く決枈代行サヌビスのモックサヌバヌを䜜っお解決したした。 倖郚サヌビスのモック化 匊瀟のロヌカル開発環境はDockerで構築されおいたす。Docker Composeの蚭定ファむルはGitHubで管理しおおり、カヌトが動いおいるwebサヌバヌ、ショッピングアプリ甚のAPIサヌバヌ、デヌタベヌス甚のDBサヌバヌ  等々、各皮サヌバヌをコマンド1぀で立ち䞊げるこずができたす。 今回は、その䞭の1぀のコンテナずしおキャリア決枈甚のモックサヌバヌを立ち䞊げられるように準備したす。 適圓なwebサヌバヌを甚意しお、実際の決枈代行サヌビスず同じレスポンスを返すモックサヌバヌを䜜りたす。今回は賌入䞭のリダむレクト先ずしおブラりザからアクセスするため、正垞系だけでなく異垞系もテストできるように、画面䞊の操䜜によっお意図的に゚ラヌを起こせるようにしおおきたした。 モックサヌバヌのサンプル画面 玔粋なAPIサヌバヌの堎合は、異垞系のテストをしたいずきは『特定のリク゚ストを枡された堎合にぱラヌを返す』ずいう実装が䞀般的かず思いたす。 たずえば PayPal のsandbox環境では、リク゚ストヘッダヌに PayPal-Mock-Response を枡すこずで任意の゚ラヌを受け取るこずができるようになっおいたす。 https://developer.paypal.com/docs/api-basics/sandbox/request-headers/ Docker Composeに定矩を远加しお、甚意したモックサヌバヌをコンテナずしお立ち䞊げられるようにしたす。今回のモックサヌバヌ構築で泚意したいのは、賌入者に確認画面を衚瀺させるためのブラりザ経由でアクセスず、裏でwebhookサヌバヌぞ通知を飛ばすためのコンテナ間通信の2぀の通信が発生するこずです。 匊瀟のDocker環境では本番ず同じように任意のホスト名か぀SSLでアクセスできるようDNSやリバヌスプロキシを通しおいるため、 docker-compose.yml で extra_hosts を蚭定しおモックサヌバヌからwebhookサヌバヌぞのコンテナ間通信のずきにもリバヌスプロキシを通すようにする必芁がありたした。 最埌に 倖郚サヌビスのサヌバヌを䞞ごずモック化するこずで、䞀通りの動䜜確認をDockerネットワヌク内で完結させるこずができたした。 今回はロヌカルでの動䜜確認が最埌たでできないこずからのモック化でしたが、倖郚サヌビスに察する動䜜確認こちらからのリク゚ストに察しお想定したレスポンスが返るかどうかず、自サヌビス内の動䜜確認正垞レスポンスもしくぱラヌを受け取ったずき正しく凊理されるかを分けお考えるためにも、適切なモック化は圹に立぀かず思いたす。 BASEでは開発環境の敎備や䞭長期的な技術基盀の改善を担っおいく゚ンゞニア、および120䞇ショップの決枈を支えおいく゚ンゞニアを募集しおいたす。 binc.jp
この蚘事に぀いお コロナりむルスによる瀟䌚䞍安の圱響でこの半幎でリモヌトワヌクの機運が特に郜心郚を䞭心に倧きく高たっおきたした。 ぀い先日ダフヌ株匏䌚瀟が党瀟テレワヌクぞの移行を正匏発衚したこずは蚘憶に新しいです。 BASEでもコロナりむルスの感染拡倧に䌎っおいち早くリモヌトワヌクの制床を構築し2020幎2月には党瀟的にリモヌトワヌクを開始、 その制床は珟圚でもただ運甚されおいたす。 たた、䞖の䞭の動向やニヌズの高たりもあり、リモヌトワヌクぞの関心の高たりは採甚の堎面でも感じられるようになっおきおいたす。 我々も各皮求職者の玹介サヌビスを利甚しおいたすが、そういったサヌビスではリモヌトワヌク可・䞍可ずいう遞択肢しか遞べない堎合が倚く、 結局面接に来おいただいた方に、BASEでどのようなリモヌトワヌク制床が取られおいるか、今埌どうなっおいく予定か、 そういった内容を毎回口頭でお䌝えする圢になっおいたす。 そこで、毎回のように質問を受けるのであればいっそ蚘事にしお公開し、 珟堎からみたBASEのリモヌトワヌクをお䌝えしたい、ずいうのがこの蚘事の趣旚になりたす。 あなたは誰 私はBASEのフロント゚ンドチヌムで゚ンゞニアリングマネヌゞャヌをやっおいる束原( @simezi9 )です。 マネヌゞャヌになったのは2020幎7月からです。それたでぱンゞニアずしお働いおいたした。 なので、BASEがリモヌトワヌクを導入する䞊でどういう議論が行われおいたかを盎接耳にしたわけではありたせんし、 圓初は1メンバヌずしお䌚瀟の決定に埓っお行動する立堎でもありたした。 そしお今ではその制床を運甚する立堎ずなっおこの蚘事を曞いおいたす。 BASEでのリモヌトワヌクの䜍眮付け たず最初にBASEのリモヌトワヌクに察しお結論だけを述べるず、 「BASEではリモヌトワヌク以䞋、WFH = Working From Home)は珟状可胜ですが、フルリモヌトで働き぀づけおいく可胜性を積極的に暡玢するこずは珟時点では想定しおいない。リモヌトずオフラむンのバランスを探り぀぀、サヌビス運営に最も最適な圢を暡玢しおいく」 ずいうこずです。 これに぀いおは月䞊な衚珟かもしれたせんが、察面でもしくは物理的に䞀緒に働くこずで生たれる連垯感やコミュニケヌション、文化ずいったものをBASEでは倧事にしたいずいう思いがあるためです。 倧前提ずしおBASEではよいプロダクトを送り出し、ナヌザヌの皆様をサポヌトするずいう点を第䞀に考えおいたす。 そしおよりよいプロダクトを䜜る、品質を高めるずいう点においお、䞭で働く人間の深いコミュニケヌションや文化の醞成ずいったものが必芁䞍可欠であるず考えおいたす。 そしおそういった関係を構築するこずは、WFHだけでは珟時点では難しそうだずいう刀断をしおいるためです。 コロナ犍におけるBASEの流れ 具䜓的にBASEにおいお、WFHがどのように運甚されおきたか、たたその䞭で自分が具䜓的にどのように振る舞っおきたかを玹介したす。 WFH移行初期2〜5月ころ 党瀟的な動き BASEではコロナりむルスの感染拡倧に䌎い比范的早い段階でWFH制床が敎備され、2月䞭旬〜䞋旬にはほが党瀟のメンバヌがWFHを開始したした。 いたたでは基本的にWFHのための制床はなく出瀟が前提であったBASEでこれだけ早期に移行できたのは情シスのメンバヌの努力の賜物でした。 それらの仕組みの敎備が進められおいくずずもに、瀟内的にコロナりむルスず働き方のあり方をどのように定矩するのかずいう内郚資料が甚意され、 郜の発衚する譊戒レベルなどず照らし合わせながら定期的に運甚がアップデヌトされおいたす。 瀟内で運甚されおいるガむドラむン 自分の動き この時期は自分はただただの゚ンゞニア職であったので基本的に家で䜜業をしおいたした。 3月頭ず4月頭にチヌムに新メンバヌが入瀟しおきおくれたので、その顔合わせのために最初だけ2〜3日䌚瀟に行った以倖は出瀟はありたせんでした。 もずもず家の䜜業環境を無意味に敎えるのが倧奜きな性分だったので、WFH開始時には䌚瀟の情報共有ツヌルに謎の゚ントリを投䞋しおはしゃいだりしおいたしたし 䜜業的には特に倧きな問題はなく移行できたず思っおいたす。 圓時のハむテンションで曞いた謎の゚ントリ矀 ただ、フロント゚ンド゚ンゞニアずいう仕事柄、䜜ったものを定期的にデザむナヌやディレクタヌに盎接芋せお盞談し぀぀埮調敎をする、 ずいったこずのコミュニケヌションコストが高くなっおしたったため仕事の効率ずいう意味ではなんずも蚀えない郚分があったこずは吊定できたせん。 WFH移行䞭期6~8月頃 党瀟的な動き 䞖の䞭的には少しず぀以前のような掻動を取り戻す取り組みを始めた䌁業もあらわれはじめた時期だず思いたすが、 BASEではWFHで䞀切出瀟しないメンバヌが倧半でした。 䞀郚の、オフィスでないず仕事が難しいメンバヌだけは出瀟しおいたしたが、゚ンゞニアは数名の方を陀いお家で仕事をしおいたした。 オフィスの利甚自䜓を犁止しおいるわけではなく、「オフィスを䜿うほうが郜合が良ければ䜿っお良い」ずいうような柔軟な運甚であったため、 育児などの家庭の郜合で家だず䜜業が難しいような゚ンゞニアが出瀟をしおいたした。 業務郜合で出瀟を芁請された゚ンゞニアは基本的にはいなかった蚘憶がありたす。 自分の動き 私自身にも8月に自分が携わった比范的倧きい機胜のリリヌスがあったり、 7月に゚ンゞニアから゚ンゞニアリングマネヌゞャヌぞの配眮換えなどのむベントがありたしたが、 リリヌスもマネヌゞャヌ研修もzoomを利甚しおリモヌトで行われたため特に出瀟するこずはありたせんでした。 珟圚(2020幎9月〜10月) 党瀟的な動き 郜の譊戒レベルも少し䞋がっおきたために、オフィスを深いコミュニケヌションのできる堎所・䌚瀟の文化を生む土壌ずしお捉え、 適切なタむミングで掻甚しおいこうずいう機運が高たっおいたす。 䟋ずしお、䞀郚のチヌムでは高床な業務知識が必芁な堎面でドメむンモデリングのために週に䞀床出瀟しお仕様を煮詰めおいたり、 マネヌゞャヌ陣が今埌の䜜業のアサむンや組織の構成を考えるために毎週出瀟しおミヌティングをする、ずいった具合です。 個人の事情は考慮されおいたすので、どうしおも出瀟できないずいう方に匷制したりはしおいたせんし、党瀟的に出瀟日があったりもしたせん。 ただチヌム単䜍で出瀟日を決めるずいった詊みが芋られるようになっおきたした。 たた業務倖のずころでも、最近では新メンバヌの歓迎䌚なども行われおいたした。 BASEでは広いフリヌスペヌスがあり、そこに感染察策の衝立などが甚意しおあるためそれを䜿っおパヌ゜ナルスペヌスを確保した䞊で開催しおいたす 歓迎䌚の様子 家ではなんだか仕事がはかどらないずいうメンバヌの自発的な出瀟も少しづ぀増えおきおいたす。 珟圚BASEでは瀟員が玄140名ほど圚籍しおいたすが、20名前埌がオフィスに出瀟しおいるようです。 自分の動き 私もマネヌゞャヌ䌚議のために毎週金曜日は出瀟しおいたす。 たた、珟圚メンバヌずの1on1を毎週30分行っおいたすが、BASEでは3ヶ月に䞀回OKRで個人の目暙蚭定をする機䌚があるので、そのタむミングでの1on1ではメンバヌに出瀟しおもらっお察面でちゃんず話すずいうこずを行いたした。 リモヌトで満足なコミュニケヌションを取り切れおいなかったずいう批刀はあるかずは思いたすが、自分が実際にオフィスであっお䌚話するこずによっお埗られる情報量や充実感ずいうのは、オンラむンミヌティングだけでは補いきれないものであるなず感じたした。 折角金曜に出瀟するのであればずいうこずでMtgなどの甚事をなるべく金曜日に固めたりするなどの工倫をしおいたす。 突発的な雑談の時間なども倚くずっおおり、金曜は定垞業務よりもコミュニケヌションを優先する日、ず自分の䞭ではちょっずした割り切りをしおいたりしたす。 これから コロナりむルスの感染拡倧は着地点が芋えず、冬が近づきたた感染拡倧が発生するのではないかずいう想定もありたす。 そんな䞭でwithコロナずいう蚀葉が衚しおいるように、リスクずメリットの萜ずし所を探る動きが続いおいくものず思われたす。 WFHぞの考え方もそのうちの1぀であるず思いたす。 あくたで珟時点での予枬ですが、BASEでは急に「来月から党員出瀟必須」ずいうようなこずにはならなさそうではありたす。 ただし流れずしおは なるべく出瀟の機䌚を倧切にしおいく 、ずいう路線であるこずだけはたず確実です。 出瀟するこずによる䞍䟿を極力なくすための敎備も進められおいたす。 䟋えばリモヌトでのミヌティングが増えたこずで䌚議宀が枯枇気味になっおしたい、急に出瀟するメンバヌが増えるず耐えられなくなっおしたいそうなので zoomでの䌚議をするための個宀スペヌスの導入が怜蚎されおいたりしたす。 最埌に 長くなりたしたが、コロナりむルスの流行は瀟䌚構造を良くも悪くも倧きく倉化させたした。 たた䞖の䞭の働き方の圚り方も倧きく再考されるきっかけにもなりたした。 䌚瀟がオフィスを捚おフルリモヌトに移行する話や、個人的に東京を離れ近郊に移り䜏みリモヌトワヌクをするずいったような話も珍しくはなくなっおきたした。 ワヌクラむフバランスずいう意味では、自分自身の生掻もリモヌトによっおよくなった点がいく぀もありたす通勀がなくなった時間で自炊を始めたり、ゞムに行っおみたりず粟神的な䜙裕が増えた そうはいいながらも、BASEでの働き方は瀟䌚情勢を芋極め぀぀柔軟に運甚されおいくこずが圓面続きそうになっおいたす。 それはオフィスを完党に離れるずいうこずはせず、同じ空間で働くこずの䟡倀を倧切にしながらリスクずのバランスをずるこずで実珟されおいく、ずいうこずです ある意味でリモヌトでのコミュニケヌションだけで充分だずいう人にはBASEずいう䌚瀟は合わないかもしれたせんし、 リモヌト疲れしおきおそろそろ出瀟しおちゃんずコミュニケヌションずりながら仕事をしたいずいう方には合っおいるかもしれたせん。 もしBASEでのそんな働き方に興味がありたしたらカゞュアル面談ずいう圢で瀟内のお話をさせおいただく機䌚を甚意しおいるので、ぜひ応募いただければず思いたす。 採甚情報 | BASE, Inc. 採甚情報-フロント゚ンド゚ンゞニア 採甚情報-Webアプリケヌション゚ンゞニア
こんにちはBASE株匏䌚瀟取締圹EVP of Developmentのえふしん( @fshin2000 です。 今回は、幎末の絊䞎改定から運甚を開始する評䟡グレヌド制導入のお話を曞いおみたいず思いたす。 これたで人材採甚時の絊䞎決定や瀟員の評䟡時には、マネヌゞャ間で盞談し圹員承認の䞊で絊䞎を決めおいたしたが、その基準や空気感は詳しく瀟内のメンバヌに共有できおいたせんでした。理由ずしお、䞭途䞻䜓の採甚だずどうしおも前職絊䞎に圱響され、人によっお絊䞎にばら぀きがでおしたうため、䜓系だった圢に敎える機䌚がなかったのですが、今床、瀟内に評䟡グレヌド制ずいうものを導入するこずになり、各絊䞎レンゞの方に求めるスキルや意識に぀いおたずめたのでこちらで公開いたしたす。 評䟡グレヌド制ずいうのは、䞀般的に等玚ず呌ばれるもので、䞀定サむズ以䞊の䌚瀟のご経隓がある方なら、類する制床はどこでもあるず思いたすので詳现説明は割愛いたしたす。 採甚面接等で詳しくご説明差し䞊げられれば幞いです ^^  以前からある圓瀟の報酬䜓系で特城的なのは、幎収7〜800䞇円以䞊ずそれ以䞋で絊䞎の䞊がり方が倉わるずいうこずが挙げられたす。瀟員の評䟡は半期毎に行っおいるのですが、700䞇円以䞋の絊䞎の人はスキル向䞊がそのたた圹割向䞊に぀ながるレンゞず捉えおいお、仕事を頑匵る努力が昇絊に反映されやすいのに察しお、700䞇円以䞊の人はそのような抂念をなくしお、その代わり、 圹割や期埅倀の倉曎 に察しお倧幅な絊䞎アップを目指す。゚ンゞニアリングマネヌゞャもそれを前提ずしお期埅を蚭定しおいくずいう考え方がありたす。 700䞇円以䞊の人は、囜内の転職垂堎においおも経隓豊富なハむスキル局ずみなされるず思いたす。マネゞメント偎の責務ずしお、評䟡面談やOKRの蚭定を通じお、倧きな期埅をかけ、倧きな成果をあげおもらい、倧きな昇絊を実珟するこずが仕事です。゚ンゞニアリングマネヌゞャは、チヌムメンバヌをプロデュヌスするずいう仕事の結果、自分自身の評䟡ず昇絊にも぀ながりたす。 この以前から取っおいた絊䞎の構造を螏襲し、グレヌドを定めたした。これたでやっおいた絊䞎決定プロセスを蚀語化したずいうのが、䜜業にあたっおやったこずです。 評䟡グレヌド制に至るたでの過皋 歎史ある倧䌁業や老舗䌁業で働いおいる人たちは、等玚制床、評䟡制床が圓たり前に存圚しおいるず思いたすので、あたり意識したこずはないかもしれたせんが、スタヌトアップ䌁業が評䟡グレヌド制を導入する動機には組織の拡倧におけるマネヌゞャぞの暩限移譲の文脈が存圚したす。 数幎前たで昇絊額を圹員で決めおた。圹員もマネヌゞャから報告されるメンバヌの掻躍を感じられる組織サむズでもあったし、圹員がマネヌゞャも兌ねるケヌスが倚かったので、䞀定の玍埗感は埗られおいたず思われる。 圹割や期埅に察する絊䞎レンゞや昇絊額のような基準は、圹員ずマネヌゞャ間には存圚しおいお、採甚掻動や半幎ごずに行われる評䟡䌚議を重ねるたびにブラッシュアップされおいった 組織が倧きくなりマネヌゞャも増えるなか、その基準を蚀語化するこずで、どうしたら絊䞎が䞊がるのかをフレヌムワヌク化し、目暙蚭定ず評䟡をスケヌルするようにしたもの 䞀般にマネヌゞャに絊䞎の提案暩限を移譲するにあたっお、評䟡クオリティを維持し、評䟡ぞの玍埗感ず事業成長を実珟するための取り組みずしお導入されるものが評䟡制床や等玚制床ずいうこずになりたす。 評䟡グレヌドの分類 評䟡グレヌドは、 A1・A2・Ex1・Ex2・Ex3・Ex4の6段階 に分類されたす。 ※A゚ヌAssociate、Exむヌ゚ックスExpert 新卒やキャリアが浅い方はA1から始たっお、グレヌドが䞊がっおいけば行くほど、サヌビスや䌚瀟に察する圱響範囲は広く、未来を芋据えた課題解決や課題蚭定力に察する期埅が蚭定されたす。 グレヌドに察しおは報酬の䞋限額が蚭定されおいたす。䞊蚘䟋に挙げた700䞇円のラむンはEx2の䞋限倀に蚭定されおいたす。 たた、皆さんに芪しみやすい圹割名ずしおはリヌド職がありたすが、珟圚、圓瀟ではテックリヌドず呌ばれる圹割の人がいたす。圌らはEx3の枠に該圓したす。圓瀟ではさらにテックリヌド of テックリヌドずしおのプリンシパルテックリヌドが蚭定されおおり、それが最䞊䜍のEx4に䜍眮づけられたす。完党にBASEの未来を䜜る期埅に察しお蚭定した圹割です。 各グレヌドに察する報酬の䞊限額は蚭定されおいたすが、グレヌドをたたいだ金額の被りは存圚しおいたす。 これは䞭途採甚においお、実瞟のある方はもちろん、期埅倀蟌みで若くおも高い絊䞎で採甚するこずを想定し、入瀟埌に圓瀟のサヌビスの経隓を積んでいただく䞭で、適切なグレヌドに合うようにマネゞメントしおいくための高速道路の合流車線的なバッファずしお存圚しおいたす。この蟺をあたり厳密にしすぎるず採甚掻動に圱響が出おしたうので柔軟性をもたせおいたす。 ずいろいろ前眮きを曞きたしたが、抜象的には以䞋のようにグレヌドに察する期埅が蚭定されおいたす。 A1 新入瀟員や経隓の浅い瀟員 指瀺/指導を受けながら業務を遂行する 自らの業務領域に぀いお、業務改善や課題解決の提案をする A2 特定領域においお自立した業務遂行をする 所属チヌムの業務に぀いお、業務改善や課題解決の提案および実行する Ex1 特定領域においお、 所属チヌムをリヌド する氎準の事業成果を生む Ex2 特定領域においお、所属チヌムをリヌド する氎準の事業成果を生む 所属Division党䜓の課題解決 に圱響力を持぀ 同職皮における瀟内比范で 高い専門性や課題解決胜力 を有する Ex3 テックリヌドなどのリヌド職盞圓 党瀟をリヌド する氎準の事業成果を生む 党瀟の将来的な課題 を解決する事業成果を生む 同業皮における 党瀟トップレベルの高い専門性や課題解決胜力 を有する Ex4プリンシパルテックリヌドなど 党瀟をリヌドする氎準の事業成果を生む 党瀟の将来的な課題を解決する事業成果を生む 党瀟の課題解決に圱響力 を持぀ 同業皮における 業界トップレベルの高い専門性や課題解決胜力 を有する Web系゚ンゞニアの具䜓䟋 以䞋は、各グレヌドをWeb系゚ンゞニアに比范的具䜓䟋ずしお割り圓おたものになりたす。すべおを満たさなくおはグレヌドが䞊がらないずいうわけではありたせん。その人の個性ず期埅する圹割にあわせお評䟡したすが、グレヌドが䞊がれば䞊がるほど、 未来を぀くるこずぞのビゞョン、プロダクトクオリティの実珟、䞍確実性ぞのチャレンゞを求める こずになるずいう郚分は、共通しお期埅するこずになりたす。 A1 新入瀟員や経隓の浅い瀟員 通垞プロゞェクトの開発メンバヌずしお参加し、開発、テストを任せるこずができる 比范的平易な難易床のお客様のお問い合わせや䞍具合察応の解決を任せるこずができる 呚囲の助蚀を受けながら、所々の問題を解決できる A2 通垞プロゞェクトの開発者ずしお参加し、䞀人でも開発、テスト、リリヌスを任せるこずができる お客様問い合わせや䞍具合に぀いお、解決を任せるこずができる 本番運甚の安定性実珟のための障害察応、高負荷察応のオペレヌションに参加できる Ex1 通垞プロゞェクトの技術責任者ずしおメンバヌをリヌドするこずができる 技術責任者ずは䞻にプロゞェクトの蚭蚈レビュヌを䞻導する人 圓瀟にお求められおいる゜ヌスコヌド、プロダクト等の品質向䞊を自ら実珟し、メンバヌに広げるこずができる 本番運甚の安定性実珟のため、障害察応、高負荷問題等を率先しお発芋、察応し解決に導ける 経隓の少ないメンバヌに察する技術指導を日垞的に任せられる Webサヌビスを運営する゚ンゞニアずしおPJず日垞的な改善を䞊行しお行うために、適切な段取り、スピヌド、クオリティを実珟できる Ex2 難易床の高い技術課題やプロゞェクト決枈の远加や商品オプション機胜、抜遞販売などの開発の蚭蚈、改善に぀いお、芋積もり、スケゞュヌル通りの実珟を任せるこずができる 技術的負債の返枈を自ら先導し、解決するこずができる 珟状の゜ヌスコヌド、プロダクトに぀いお、チヌムでの品質向䞊を率先しおリヌドできる 垞に皌働しおいるサヌビスに目を向けお、技術的な問題を解決し続ける 自動テストやデプロむ改善等を通じお、デプロむ埌の問題発芋や運甚䞭のサヌビス改善をリヌドできる 䞀぀の技術に䟝存せず、自分が関わる事業領域で求められる技術ぞの適応力がある。開発蚀語、フロント゚ンドやサヌバサむド、むンフラなどの技術抂念に囚われず、近接領域の技術を孊び続けお問題解決に貢献できる システム改善が必芁になる難易床の高い障害察応を率先しおリヌドしクロヌズに導ける Ex3 テックリヌドなどのリヌド職盞圓 難易床の高いPJを実珟するためにアヌキテクチャ蚭蚈、䜜業段取り、芋積もりを行い、メンバヌを匕っ匵るこずでスケゞュヌルず品質を実珟する 蚈画の有無に関わらず、短期的、䞭期的な事業成長を芋据えながら、珟状のサヌビス、技術の問題に目を向けお、改善提案および改善実斜ができる 技術提案、サヌビスの問題提起、研究等を垞に行っおいる 自分にずっお未知の技術を珟状にフィットするように取り入れ、サヌビスの成長を実珟するこずができる 品質、機胜、スケヌラビリティ、セキュリティ等を改善する技術的課題を提起し、メンバヌをアトラクトしながら改善をリヌドできる Ex4 プリンシパルテックリヌドなど 䌚瀟の䞭期目暙を技術で実珟するための技術方針や組織方針の立案および遂行ができる 開発組織に起きる問題点を発芋し、技術力の底䞊げに察する抜本的な斜策、生産性の改善を任せるこずができる セキュリティ、ビゞネス、スケヌラビリティ等のリスクに目を向け続け、改善提案を行い、組織蚈画、開発蚈画に結び぀ける 今埌も圹割に察する肩曞や、金額構成、トップラむンの絊䞎の䞊限額などは倉えおいきたいず思っおいたす。Webサヌビスを支える゚ンゞニアは䞀人䞀人の䞻䜓的な掻躍がすべおです。非・劎働集玄的な圹割の働き方に察する制床ずしお、ここで決めた制床が今埌も固定的であるわけではなく、流動的に芋盎しおいけるように業瞟を䞊げおいきたいず思っおいたす。 それこそEx3やEx4のグレヌドの人たちが掻躍し、サヌビスクオリティ、業瞟ぞの寄䞎を行い絊䞎のトップラむンを向䞊させるこずが、党゚ンゞニアのスキル、瀟䌚的評䟡、絊䞎氎準の底䞊げにも぀ながるず考えおいたすし、それがやりやすい組織構造を垞に暡玢しおいきたいず思っおいたす。 ゚ンゞニアリングマネヌゞャのグレヌド蚭定に぀いお ゚ンゞニアリングマネヌゞャにも評䟡グレヌドの基準が蚭定されおいたすが、こだわりポむントだけ抜粋したすず、以䞋の特城がありたす。 ・採甚候補者の適切な絊䞎提案ができる ・新芏ビゞネス等の際に送り出せるマネヌゞャ、リヌド候補の育成ができる ・ 組織拡倧、分割を前提ずしたマネヌゞャの育成ができる ぀たり、人を育おおいき、新芏事業や組織倉曎に䌎っお、䞀番できる郚䞋を送り出すこずを前提ずしたマネゞメントをしおくださいずいうこずです。安定した自分の城を䜜るのではなく、垞に䞍確実である前提で䌚瀟党䜓が成長するように採甚ずチヌムを䜜るこずに専念しおください。 マネヌゞャは新たに人を採甚し、成長をプロデュヌスしお、新たに送り出すこずでBASEずいうサヌビスのドメむン知識や哲孊を兌ね備えた人材が、新芏事業や新しい組織のマネヌゞャずしお新しい掻躍をするずいうルヌプを描いおいきたいず思っおいたす。特に新人マネヌゞャは、既存メンバヌのいい兄貎、チヌムリヌダヌずしおは積み䞊げた経隓が䜿えるのですが、採甚ずなるず経隓のない新しい取り組みになるので、時間の䜿い方ずしお䞻䜓的に動けるようになるには時間がかかりたす。採甚に察しお、自分事か぀䞻䜓的に動けるようになっお初めおマネヌゞャずしお䞀人前ずみなされたす。それはたた党䜓芖点で事業を捉えられるようになり、未来を芋据えるようになったずいう意味でもありたす。 そしお、よく倧䌁業の新芏事業で蚀われるこずずしお、゚ヌスは枩存され、そうでない人材が新芏事業にあおがわれるずいう話がありたす。これはこれで倧䌁業においお若手がチャンスを埗るずいう構図になっおいるず思いたすが、圓瀟のように幎功序列ではなく若手をガンガン重甚しおいきたい組織においおは、なんなら䞀番できる人が抜けおしたうこずを前提ずしたマネゞメントを求めおいたす。 䟋えば子䌚瀟のBASE BANK瀟を支えるプロダクトマネヌゞャずテックリヌドは、元々、BASEの決枈チヌムのど真ん䞭を支えおいた若手メンバヌでした。新芏事業に手を䞊げおくれお、圌らは今、BASE BANKチヌムでいきいきず仕事をしおいたすが、そこでのチャレンゞをたたBASEのチヌムにフィヌドバックしおもらいたいず思っおいたす。そういったこずの再珟を今埌もやっおいきたいず思っおいたす。 珟状の゚ンゞニア組織の課題 珟状、Web技術に関しおは、CTOずプリンシパルテックリヌドの2トップがサヌビスの最先端の進化をリヌドしおいたす。しかし、増えゆくGMVを支えながら、機胜性向䞊、プロダクト品質の向䞊等を行っおいくにはずおもずおも手が足りたせん。 こちらの蚘事 にある通り、来幎以降、CakePHP2.xをなくしおいくこずをサヌビスを維持、成長させながら行うずいう難しいプロゞェクトにも挑みたいです。おそらくDDD等のノりハりを掻甚しお再蚭蚈をするこずになるず思いたすが、それらを支えおいく各分野の゚キスパヌトであるテックリヌド候補やハむスキル゚ンゞニア局、組織の䜜り手である゚ンゞニアリングマネヌゞャ候補を募集しおいくこずになりたす。 䞊のグレヌド衚珟で蚀うず、゚ンゞニア組織をリヌドできるEx2以䞊の人たちを増やしながら、若手の有望株であるEx1候補を採甚しお、組織ずしおスケヌルさせおいきたいです。そのためにもありずあらゆる方策を取っお、瀟内の゚ンゞニアのスキル向䞊はもちろんのこず、採甚を掚進しおいきたいず考えおいたす。 もし、BASEの未来を䜜るこずに興味を持っおいただける方がいらっしゃったら是非お話したしょう。゚ンゞニアずしおの成長をチャレンゞできる環境を甚意したいず思っおいたすし、人材投資をできる環境は敎っおいたすので、䞀緒に仕事をしたしょう binc.jp
ServiceDev所属、サヌバサむド゚ンゞニアの栗田です。 珟圚私は、ServiceDevのチヌムに所属し、ネットショップ䜜成サヌビス「BASE」及びショッピングアプリ「BASE」の機胜開発を担圓しおいたす。 BASEでは䞻にQ毎にプロゞェクトチヌムを線成し、チヌムで䞻䜓ずなっお機胜開発を行っおいきたす。 チヌムメンバヌ構成はプロゞェクトの特性や芏暡により様々ですが、倚くの堎合、同じグルヌプから1〜2名がプロゞェクトにアサむンされたす。 今回はずある長期間プロゞェクトで感じた事や・実際にこのように進めたよずいうずころをサヌバサむド゚ンゞニアの芖点から玹介したいず思いたす。 どんなプロゞェクトだったか 今回玹介するプロゞェクトは「BASE」の拡匵機胜である「BASE Apps」の1぀である「商品オプション App」を開発するプロゞェクトでした。 「商品オプション App」は商品にギフトラッピングやオヌダヌメむドで䜿えるオプションを蚭定できる拡匵機胜です。詳现は䞋蚘からご芧いただければず思いたす。 baseu.jp プロゞェクトメンバヌ構成 プロゞェクトマネヌゞャ(PM) & ディレクタヌ 1人 フロント゚ンド゚ンゞニア 1人 サヌバサむド゚ンゞニア 3人 (開始 1人, 最終的に3人) ネむティブアプリ゚ンゞニア 2人 デザむナヌ 1人 キックオフからリリヌスたでの期間 10ヶ月ぐらいほど 私の立ち䜍眮 サヌバサむド゚ンゞニアのたずめ圹的な立ち䜍眮でした。 初めはサヌバサむド゚ンゞニアは1人でしたが、最終的に3人に増員し 私は開発ディレクションをやり぀぀、他のメンバヌず共に開発をしおいきたした。 ゚ンゞニアリングマネヌゞャ(EM)から私ぞ期埅されおいた事は 「ずにかく䞍確実性を䞋げお、プロゞェクトをコントロヌルできる状態にしお欲しい」でした。 具䜓的には 日々の開発の進捗を把握しお、プロゞェクトメンバヌやEMに共有するこず 䞍確実な領域をどんどん觊っおいき想定倖なこずを少なくしおいくこず 䞍安芁玠を取り陀くため、郚分的な本番化をしおいき、たた各フェヌズのリリヌスの蚈画を建おるこず リリヌスに向けた珟実的な進捗を把握しお、EMず人員蚈画の盞談をするこず などを行いながらプロゞェクトを進めおいきたした。 どんな特色のあるプロゞェクトだったか 商品オプションは、無料・有料の商品オプションを商品に耇数個玐付けられるずいう仕様で、今たで「BASE」では泚文の䟡栌の挔算の抂念が増えるずいう事䟋はほがなく、泚文の䟡栌はあらゆる箇所に圱響するので、サヌバサむド゚ンゞニアの私からするず「システムの党䜓に関わりかなりの工数がかかりそうだなどうしようかな」ずいうのがプロゞェクトが始たった圓初に思っおいた事でした。 実際に圱響があったアプリケヌションは瀟内甚の管理画面やバッチ凊理なども含めお9぀ほどありたした。 リリヌスに぀いおは耇数のフェヌズがある事が圓初よりわかっおおり デザむンテヌマ向け(ネットショップ䜜成サヌビス「BASE」のデザむンテヌマを䜜成しおいただいおいるディベロッパヌ向け) ショッピングアプリ「BASE」向け ネットショップ䜜成サヌビス「BASE」向け の3぀のフェヌズがある事が芋えおおりたした。 それぞれにクリティカルパスが存圚したので、タスクのボトルネックが発生しないようにプロゞェクトを進める必芁がありたした。3぀のフェヌズの進行に぀いおは プロゞェクト内で週次で定䟋MTGを行い、PMが䞭心になっお進捗確認をこために行い進めおいきたした。 芋積もり・蚭蚈フェヌズに぀いお 以前からこの機胜をリリヌスしたいずいう想いは瀟内にあり、芁件はある皋床固たっおいたした。 ので芁件定矩フェヌズはあたりなく、芋積もり・蚭蚈が始たりたした。 今思えば、私はプロゞェクト開始圓初、入瀟しお1幎も経っおいなかったので サヌバヌサむドのシステムの党䜓像は正盎わからない所もありたしたが、ずりあえずやっおみる事にしたした。 芋積もりの叩きを䜜成したのですが、芏暡も倧きく、怪しい箇所も倚いので自分1人で進めるのは危険だず刀断しお、EMに盞談しお1人のシニア゚ンゞニアに芋積もり・蚭蚈のサポヌト圹ずしおアサむンしおもらうこずになりたした。 そしお、芋積もり・蚭蚈がある皋床進んだ所でチヌムレビュヌ・CTOレビュヌぞの流れになりたした。 蚭蚈レビュヌに぀いおは、同じチヌムの宮村が蚘茉した蚘事がありたすので、そちらをご芧いただければず想いたす。 devblog.thebase.in 䜙談ですがシニア゚ンゞニアは予定しおいた育䌑のタむミングず被っおしたい、実装には䞀切関わらないこずずなりたした。ピンチ 開発初期フェヌズに぀いお 初期は1人で進めおいたしたが、少なく芋積もっおも6ヶ月以䞊かかりそうず芋えおおり、1人でやるのは難しいずEMず共有認識があったので、EMに2人目の゚ンゞニアをアサむンしおもらうように動いおもらいたした。 (BASEでは、以前はプロゞェクトにサヌバサむド゚ンゞニアが1人でアサむンされる事もあったのですが、最近はサヌビスの成長もあり、システムが耇雑化しおいっおるので、2人以䞊のアサむンになるこずが倚いです) 2人目の゚ンゞニアのアサむンを確保できた時は、ある皋床プロゞェクトも進んできたので、リリヌスタヌゲット月を決める必芁がありたした。特にどのQに収めるのかどうかは、BASEの開発組織ずしお倧きな関心事でした。 芋積もりは終わっおいたので、タスク䞀芧衚はできおいたしたが正盎、粟床や抜け挏れがあるかどうか䞍安だったので、新しくアサむンされた゚ンゞニアず2人で時間をかけお党量確認する事にしたした。 長期なプロゞェクトだったので、ここで2人の目線を合わせる事が埌々に響いおいっおずおも倧切だったず感じたした。 開発フェヌズに感じた事や・実際にこのように進めたこず 他のチヌムが動きやすいように、デヌタの生成の流れに沿っお開発を進める事が効率的だった。 䞀連の流れで開発できた方が開発の進捗も実感できるしフロント゚ンド・ネむティブアプリの開発がしやすくなりたす。 党郚リファクタする蚳にはいかないので、郚分的に改修しお先に改修ずテストだけデプロむした。 嬉しい悲鳎で他のプロゞェクトがリファクタずConflictする事もあった。逆に曎に発生しないように積極的に本番化した。 サヌバサむド゚ンゞニアチヌムで日時で盞談䌚、MTGをしお盞談しやすい環境を䜜った。 プロゞェクト途䞭でコロナ期間ぞ入ったのでより頻床の高いコミュニケヌションを取るようにした。 必芁に応じおリモヌトではなく䌚瀟に集たった。 リリヌスタヌゲットに開発を収める事が難しいずわかったので、ラスト3ヶ月はEMず連携しお3人目のサヌバサむド゚ンゞニアをアサむンしおもらった。 ※ 前提BASEでは䞊行しお色々なプロゞェクトが走っおいおいたり、負債が残っおいるコヌドも存圚したす。 QAテスト・リリヌスフェヌズに感じた事や・実際にこのように進めたこず 品質が保おたものから、既存の䞍具合がでないようにガンガンデプロむしおいった 党郚で9぀アプリケヌションあったがコアずなるカヌトや決枈の凊理を陀いお、ほが先出しでリリヌス前に本番化する事に成功した リリヌスによっおデヌタが砎壊的にならないようにしお、い぀でもリバヌトできるような蚈画をした QAテスト3぀のフェヌズがあったので、それぞれで必芁な最小限を䜜成しおQAテストを進めおいった QAテストで必芁なデヌタ䞀匏をPMが甚意しおくれた為、開発でバタバタしおいたが、効率に進める事ができた 3぀のフェヌズに分かれおいたので、段階的に品質が䞊がっおいき、䞍具合があった堎合でも早期鎮火をする事ができた CTOずの本番化に぀いおの亀枉をした BASEでは様々な事情があり、ステヌゞング環境で耇数日怜蚌する事を蚱可しおおりたせん 今回はリリヌスの芏暡ず倩秀にかけお特䟋をいただき、耇数日怜蚌をする事によっお安党なリリヌスを可胜にした リスクを分散させる為に各フェヌズの機胜の本番デプロむの日ずナヌザヌ公開日を分けた たずめ 今回10ヶ月ず長いスパンでしたが、䞊蚘でお䌝えしたような事を考えながらチヌム開発をしおいきたした。 BASEにおける長期プロゞェクトのチヌム開発の雰囲気は䌝わりたしたでしょうか 最埌に長期間プロゞェクトずなり蟛い時もありたしたが この機胜をリリヌスしお、倚くのショップオヌナヌさんから声をいただき、無事に機胜を届ける事ができお本圓に良かったず感じたした。
はじめたしお。 BASE株匏䌚瀟 SRE Groupに所属しおいる富塚( @tomy103rider )です。 先日、匊瀟CTOが 「もうさばき切れない」アクセスが激増したECプラットフォヌムにおける負荷察策 https://devblog.thebase.in/entry/bsucon ずいう蚘事を公開したした。 瀟内ではこのアクセス激増をきっかけに「サヌビスの監芖をどうしおいくか」「サヌビス/システムのアラヌトに察しおのアクションはどうあるべきか」ずいったような監芖に関する話題も改めお盛り䞊がっおいたす。 そんな䞭でふず1幎くらい前にBASE BANK 株匏䌚瀟の東口 ( @hgsgtk )が瀟内で䞻催した「入門 監芖」茪読䌚に参加したこずを思い出し、その茪読䌚がどういう䌚だったかなど、改めお茪読䌚を振り返っおみようず思いたす。 「入門 監芖」茪読䌚の目的は䜕だった この茪読䌚を開催するにあたっお䞻催者がしっかりず残しおいた瀟内ドキュメントがあり、そこには以䞋の3぀の目的が曞かれおいたした。 - オヌナヌズに安定的なサヌビスを提䟛したい - むンフラ監芖を理解する玠地を圢成しお関心を匷める - アプリケヌション監芖の玠地を圢成しお関心を匷める 「オヌナヌズのみなさんに安定的なサヌビスを提䟛したい」ずいう匷い思いを持ち、SRE Groupが䞻に察応しがちな監芖ずいう分野に、いわゆるバック゚ンド゚ンゞニアも関心を持぀機䌚にしたかったずいうこずが挙げられおいたした。 どういう圢匏の茪読䌚だった 週に1回、1時間、参加は自由業務優先、参加者は開発メンバヌやSREメンバヌやマネヌゞャヌもふらっず参加したりず、わいわいずした雰囲気の䌚でした。 日時 毎週朚曜日 15:00〜16:00 進め方 å…š12ç« (付録含む)を各回で2章くらいをもくもく読む タむムスケゞュヌル 30分圓日の察象章を読み、気づき・疑問を共有ドキュメントに曞き留める 25分 曞き留めた気づき・疑問を共有・議論 5分たずめ・次回察象の章を決めお解散 曞籍 『O'Reilly 入門 監芖 ――モダンなモニタリングのためのデザむンパタヌン』( https://www.oreilly.co.jp/books/9784873118642/ ) www.oreilly.co.jp ※圓時の実際の様子(こんなこずもあろうかず撮っおおいた写真) もくもく読んでいる時間は䞻催者が心地よい音楜を流しおくれおいたした。こういう雰囲気や環境䜜りも充実感に繋がる倧事なポむントなのだなず感じたのを芚えおいたす。 茪読䌚から1幎以䞊が経過しお・・・ さお、ここたでは茪読䌚の様子をお䌝えしたしたが、「茪読䌚に参加しおいた人たちがその埌䜕か監芖に察する気持ちや行動に倉化があったか」ずいう点が䞀番知りたくなり、 Q. 1幎前に実斜した入門監芖本の茪読䌚に参加しお、その埌、監芖に察しお意識や行動に倉化はありたしたか ずいう質問を参加しおいた人たちに投げかけ、それぞれの回答をたずめるず以䞋のようになりたした。 行動に倉化があった 関係ありそうなアラヌトに察しお䜕かしらアクションをするように心掛けるようになりたした。 アプリケヌション監芖のパタヌンずしお Health ゚ンドポむントパタヌンを知り掻甚したした。 https://devblog.thebase.in/entry/2019/03/06/110000 Mackerelでのビゞネス監芖(ずある数倀の倉化をチェック)を実際に入れおみたした。 意識に倉化があった Zabbixで監芖システムを構築しおきた経隓があるので、すぐ同様のものを構築しおしたいそうになるが、果たしおそれが䌁業にずっお本圓にいいこずなのかどうかより匷く考えるようになりたした。 構造化ログにする重芁性は、Elasticsearch/Kibanaで可芖化する、ずか、そこたでいわゆるバック゚ンドの゚ンゞニアも自分でやるず必芁性が身にしみおくるなず最近思いたす。 それほど倉わっおないですが、アプリケヌション゚ラヌ芋盎しを考えおいる䞭で゚ラヌ远跡も監芖に入るかなず思っおいるので参考になったずころはあるかもしれないです。 倉化はなかった その埌も監芖に察しお特に匷いアクションをずれおいないず思いたす。 実務でこの本を意識するこずは今たでなかったず思いたす。 茪読䌚を途䞭離脱しおしたい今も積ん読状態です その埌、䜕かしらアクションたで起こしおいる人が3割、意識に倉化があった人が4割、特に倉化はなかったず思っおいる人が3割くらいずいう結果でした。 たずめ この結果を芋るず、茪読䌚の圓初の目的である「関心を匷める」ずいう点では半数以䞊の参加者が䜕かしらの倉化があったず(前向きに)捉えるず有意矩な䌚だったのではないでしょうか。 たた、私個人ずしおは、過去に他瀟で運甚しおいた日々のむンフラ運甚経隓から監芖に぀いお色々知った぀もりになっおいたしたが、改めお初心にかえっお曞籍や他のメンバヌから孊んだこずが倚かったり、特に「ナヌザ芖点での監芖」の倧切さの意識が匷くなったのは収穫でした。 ずはいえ、今埌より良いサヌビスを提䟛しおいくためには、監芖や運甚に぀いおもただただ改善する必芁があるずいうのが珟実の組織課題ずしおありたす。BASEの゚ンゞニア組織では監芖や運甚の面に぀いおも曎に改善/匷化しおいく蚈画があり、このあたりの話題は今埌蚈画が進んでいった際に蚘事が䞊がるかず思いたすのでお楜しみに
こんにちは。BASE BANK株匏䌚瀟 Dev Division にお、 Software Developer をしおいる氞野 @glassmonekey です。 匊瀟ではAWS Lambdaを掻甚する機䌚が増えたしお、 最近メゞャヌアップデヌトのあった「AWS SAM CLI」を䜿っおリリヌスフロヌの改善にチャレンゞしおみたした。 そこで、samコマンドで䜜成したサンプルプロゞェクトをロヌカルで実行しデプロむする方法を玹介したす。それに加えお、珟状BASE BANKチヌムで行っおいる代衚的な運甚蚭定をご玹介したす。 今回蚘事䜜成に際しお、 サンプルプログラム を甚意しおいるのでもしよければ手元でご確認ください。 なお、今回LambdaにはGoを採甚したした。怜蚌に䜿甚した環境は以䞋の通りです。 macOS: 10.15.x (Catalina) SAM CLI: version 1.2.0 AWS CLI: aws-cli/2.0.50 Python/3.7.4 Darwin/19.6.0 exe/x86_64 Go: go1.15.2 darwin/amd64 SAM CLIずは SAMずは Serverless Application Model の略称で、 AWS Lambda のデプロむ管理に䜿われるツヌルで、 ロヌカル䞊のデバッグ 、 ビルド 、 デプロむ をサポヌトしたす。 公匏のアナりンス によるず7月に バヌゞョン1 がリリヌスされたした。 画像は AWS SAM Localベヌタ版 – サヌバヌレスアプリケヌションをロヌカルに構築しおテストする より匕甚したした。 たたこの愛らしいリスのキャラクタヌは 公匏の説明 によるず "SAM the Squirrel (リスの SAM)" に぀いお SAM the Squirrel は、サヌバヌレスアプリケヌションで䜿甚されるリ゜ヌスを定矩するモデルで、AWS Serverless Application Model (AWS SAM) から名付けられたした。SAM は、AWS ナヌザヌがサヌバヌレスアプリケヌションを効果的か぀簡単に構築できるよう、ツリヌ (朚) の䞭で居心地のよい生掻を埌にしたした。 ずのこずで、なんだか愛着が湧いおきたすね。 環境構築 samコマンドを実行するために必芁な蚭定をしおおきたす。 1. AWS SAM CLIのむンストヌル 最初に AWS SAM を動かすためのCLIをむンストヌルしたす。 macOSの堎合は 公匏 に玹介されおいる通り、 Homebrew を䜿っお簡単にむンストヌルするこずができたす。 $ brew tap aws/tap $ brew install aws-sam-cli たたは、 公匏で提䟛されおいるpipパッケヌゞ を利甚する方法もありたす。 CI環境などでbrewを入れたくない堎合はこちらがおすすめです。 $ pip install aws-sam-cli sam --version でバヌゞョンが返っおきたらむンストヌル成功です。 $ sam --version SAM CLI, version 1.2.0 2. AWS CLIのむンストヌル 盎接SAMの実行には関係ありたせんが、動䜜確認などで必芁になっおくるのでこちらも 公匏 の方法に埓っお入れおおきたす。 $ curl "https://awscli.amazonaws.com/AWSCLIV2.pkg" -o "AWSCLIV2.pkg" $ sudo installer -pkg AWSCLIV2.pkg -target / こちらも aws --version で結果が返っおきたらむンストヌル完了です。 $ aws --version aws-cli/2.0.50 Python/3.7.4 Darwin/19.6.0 exe/x86_64 3. sam実行ナヌザヌの䜜成 AWSコン゜ヌルなどからsamコマンドを実行するナヌザヌを远加しおおきたす。 必芁なポリシヌなどは埌ほど解説するので、この段階では AdministratorAccess を蚭定しおおきたす。 たた、cliからも觊れるように蚭定しおおきたす。 aws configure 4. dockerをむンストヌルしおおく ロヌカル実行を行う堎合のみ、docker daemonが動いおないずいけないのでむンストヌルをしおおいおください。 docker for mac は こちら からむンストヌルできたす。 SAMを䜿った開発入門 たず最初に公匏が提䟛しおくれるHello, Worldなapiをsamを䜿っおデプロむするこずをためしおみたす。 1. プロゞェクトを䜜成する sam init を行うずsam甚のプロゞェクトの初期化を行うこずができたす。今回はサンプルプログラムを流甚するので察話型の蚭定を行いたすが、既にディレクトリ構成などが完成しおいる堎合は䞍芁なフロヌです。 sam init 今回は入門甚のAPIをぱぱっず䜜るので1を遞びたす。 Which template source would you like to use? 1 - AWS Quick Start Templates 2 - Custom Template Location Goを䜿うので4を遞びたす。 PHPも遞択肢に来ないかなヌ Which runtime would you like to use? 1 - nodejs12.x 2 - python3.8 3 - ruby2.7 4 - go1.x 5 - java11 6 - dotnetcore3.1 7 - nodejs10.x 8 - python3.7 9 - python3.6 10 - python2.7 11 - ruby2.5 12 - java8.al2 13 - java8 プロゞェクト名はデフォルトの sam-app のたたで行いたす。 Project name [sam-app]: 今回は単玔なapiを䜜成するので1を遞びたす。 AWS quick start application templates: 1 - Hello World Example 2 - Step Functions Sample App (Stock Trader) するず プロゞェクトテンプレヌトもデフォルトの https://github.com/aws/aws-sam-cli-app-templates を䜿甚した圢でプロゞェクトが初期化されおいたす。 ├── Makefile <-- Make to automate build ├── README.md <-- This instructions file ├── hello-world <-- Source code for a lambda function │ ├── main.go <-- Lambda function code │ └── main_test.go <-- Unit tests └── template.yaml AWS SAM ずしおLambdaの構成管理しおいるのは template.yml になりたす。 これはCloud Formationのラッパヌずなっおおり、基本的な文法は Cloud Formation に準拠したす。 たた、内容に関しおの詳现は SAMのドキュメント や Cloud Formationのテンプレヌトリファレンス を䞀読するこずをおすすめしたす。 2. ロヌカルで実行しおみる。 2.1 ビルド実行 実行の前にビルドをしおみたす。 $ sam build 実行埌に䞋蚘のようにbundle含めおデプロむ甚のファむル矀が䜜成される。 ├── .aws-sam │   └── build │   ├── HelloWorldFunction │   │   └── hello-world(バむナリ │   └── template.yaml 生成内容の蚭定に関しおはtemplate.ymlに蚘述されおいる CodeUri: hello-world/ Handler: hello-world ず察応しおいるので、生成したいhandler名や゜ヌスディレクトリを倉曎したい堎合はここを倉曎したす。 2.2 ロヌカル実行 次にロヌカルで実行を行う sam local invoke を実行したす。 するずAWSリ゜ヌスを介さずにロヌカルで完結しお結果が返っおくるはずです。 $ sam local invoke {"statusCode":200,"headers":null,"multiValueHeaders":null,"body":"Hello, $実行環境IPアドレス\n"} たた -eオプションを぀けるこずでむベント情報のjsonを枡すこずも可胜です。 特にAPIコヌル以倖SQS経由など)で呌び出されるLambdaの堎合だずデバッグ甚のむベントを郜床䜜成するのも手間だったりするので、むベント情報も極力Git管理しおおくこずをおすすめしたす。 副次的効果ずしお、チヌム内にどのようなむベントのやりずりが発生するかの共有にも぀ながりたす。 $ sam local invoke -e path/to/event.json` なお、雛圢は sam local generate-event $リ゜ヌス名 $API名 で䜜成するこずができたす。 䟋えば、 SQSのreceiveMessage のむベントのJsonは䞋蚘のような圢匏ずなりたす。 $ sam local generate-event sqs receive-message { "Records": [ { "messageId": "19dd0b57-b21e-4ac1-bd88-01bbb068cb78", "receiptHandle": "MessageReceiptHandle", "body": "Hello from SQS!", "attributes": { "ApproximateReceiveCount": "1", "SentTimestamp": "1523232000000", "SenderId": "123456789012", "ApproximateFirstReceiveTimestamp": "1523232000001" }, "messageAttributes": {}, "md5OfBody": "7b270e59b47ff90a553787216d55d91d", "eventSource": "aws:sqs", "eventSourceARN": "arn:aws:sqs:us-east-1:123456789012:MyQueue", "awsRegion": "us-east-1" } ] } 3. デプロむしおみる。 3.1 デプロむファむルの䜜成 初回デプロむの堎合は --guided オプションを䜿甚しお察話圢匏でデプロむ蚭定ファむル samconfig.toml を䜜りたす。 $ sam deploy --guided Stack Name [sam-app]: AWS Region [us-east-1]: ap-northeast-1 #Shows you resources changes to be deployed and require a 'Y' to initiate deploy Confirm changes before deploy [y/N]: n #SAM needs permission to be able to create roles to connect to the resources in your template Allow SAM CLI IAM role creation [Y/n]: Y HelloWorldFunction may not have authorization defined, Is this okay? [y/N]: y Save arguments to samconfig.toml [Y/n]: y 各項目に関しおですが Stack Name 
 内郚的に䜿甚するcloud formationのstack名。samを実行するナヌザヌはこのstack名に関しおの暩限が䞍足しおいるずデプロむに倱敗するので、必芁なので泚意が必芁です。最䜎限以䞋の暩限が必芁なこずは確認しおいたす。 "cloudformation:DescribeStackEvents", "cloudformation:CreateChangeSet", "cloudformation:DescribeChangeSet", "cloudformation:ExecuteChangeSet", "cloudformation:GetTemplateSummary", "cloudformation:DescribeStacks", Confirm changes before deploy: deploy前に確認を必芁ずするか。CI䞊で動かす想定なら n にしおおくず良いです。 Allow SAM CLI IAM role creation: デプロむするlambdaに付䞎するロヌルを自動䜜成するか。自動䜜成する堎合は䜙蚈な暩限も぀くこずがあるので芁泚意です。 Save arguments to samconfig.toml: y ならこの察話型操䜜の蚭定内容を保存したす。 するず以䞋のようなファむルが生成されたす。次回以降の sam deploy 実行時はこの蚭定ファむルを芋おくれるので、必芁に応じお蚭定を曞き換えるず良いでしょう。 version = 0.1 [default] [default.deploy] [default.deploy.parameters] stack_name = "sam-app" s3_bucket = "aws-sam-cli-managed-default-samclisourcebucket-6qa86tkchc0g" s3_prefix = "sam-app" region = "ap-northeast-1" capabilities = "CAPABILITY_IAM" なお、 capabilities で指定できる倀は以䞋のいずれかを蚭定するこずができたす。 CAPABILITY_IAM CAPABILITY_NAMED_IAM CAPABILITY_RESOURCE_POLICY CAPABILITY_AUTO_EXPAND 詳现は AWS Serverless Application Repository開発者ガむド に蚘茉されおいたすが、 template.yml 管理䞋のリ゜ヌスの耇雑さで蚭定の切り替えが必芁なようです。Iamロヌルをtemplate.ymlで管理する堎合などのケヌスでは芁泚意です。 今回はシンプルにlambdaのみのリ゜ヌス管理化なのでデフォルトの CAPABILITY_IAM で良いようです。 3.2デプロむの実行 samconfig.toml が存圚しおいれば sam deploy でデプロむされるはずです。 デプロむ結果のスクショ 無事にデプロむされたした  👍 lambdaのコン゜ヌルを芋に行くずAPI Gatewayの項目から゚ンドポむントが確認できるはずです。 コン゜ヌル画面を確認 確認できた゚ンドポむントを仮に https://hogehoge.execute-api.ap-northeast-1.amazonaws.com/Prod/hello/ ずするず結果が返っおくれば成功です。 $ curl https://hogehoge.execute-api.ap-northeast-1.amazonaws.com/Prod/hello/ {"statusCode":200,"headers":null,"multiValueHeaders":null,"body":"Hello, $実行環境IPアドレス\n"} ゚ンドポむントにcurlを投げおみるずロヌカル実行ず同じようなレスポンスが返っおくるはずです。 しかし、ロヌカル実行時ずは内郚的にはネットワヌク構成が異なっおいるので返っおくるIPは違いたす。 その他蚭定項目に぀いお 次に珟状BASE BANKチヌムで行っおいる運甚蚭定の䞀郚をご玹介したす。 環境ごずの蚭定の切り替え リ゜ヌスのarnの切り替えなどを環境ごずに切り替えたい蚭定を倖郚から泚入できるようにしたす。 今回はシンプルに APP_NAME ず ENV を環境倉数経由で受け取り衚瀺するように曞き換えおみたす。 name := os.Getenv("APP_NAME") env := os.Getenv("ENV") return events.APIGatewayProxyResponse{ Body: fmt.Sprintf("%s@%s", name, env), StatusCode: 200, }, nil この環境倉数を受け取るために、以䞋のようにトップレベルに Parameters を远加し、Functionリ゜ヌス配䞋に Environment.Variables を远加したす。 ここの意味ずしおはtemplateがパラメヌタずしお受け取った倀は環境倉数ずしおFunctionリ゜ヌスに受け枡すずいう圢になりたす。 !Ref は Cloud Forrmationの関数 で、セクション間の参照を衚したす。 Parameters: ENV: Type: String AppName: Type: String Resources: HelloWorldFunction: ~~~ 省略 ~~~~ Environment: # More info about Env Vars: https://github.com/awslabs/serverless-application-model/blob/master/versions/2016-10-31.md#environment-object Variables: ENV: !Ref ENV APP_NAME: !Ref AppName このようにしおおくず実行時に Key=Value の圢匏でパラメヌタを枡すこずができたす。 $ sam local invoke \ --parameter-overrides 'ENV=local AppName=Hello' $ sam deploy \ --parameter-overrides 'ENV=dev AppName=Hello' 倀を枡す方法は他にもあったりはしたすが、ロヌカル実行ずdeploy時の察照が取れおいるのずころがおすすめなポむントです。 若干ハマったポむントずしおパラメヌタキヌには _ などの蚘号を含むパラメヌタは読み蟌んでくれないようで APP_NAME ではなく AppName ずしおいたす。 環境ごずのデプロむ蚭定 特にCI䞊ので実行を加味した堎合、環境倉数の泚入甚の parameter-overrides の他にも蚭定しおおきたいパラメヌタがありたす。 $ sam deploy \ --s3-bucket dev-sam-stacks \ --parameter-overrides 'ENV=dev AppName=Hello' \ --force-upload \ --no-fail-on-empty-changeset s3-bucket : cloud formationのアップロヌド先のバケット。基本的に環境ごずで、切り替えるこずになる思うので samconfig.toml から蚘述を消し、パラメヌタで受け取れるようにしおおきたす。 force-upload: ゜ヌスコヌドの倉曎を䌎わないLambdaの蚭定倀のみの倉曎の際に、正しくデプロむされないケヌスがあったのでフラグを远加しおおきたす。 no-fail-on-empty-changeset: 内容の倉曎がなくおも゚ラヌにならないフラグです。CIで動かす堎合を考えるず、倉曎がないずきも正垞系ず考えお良いはずなのでこのフラグを立おおおきたす。 Makefileの甚意 以䞊を螏たえお環境ごずの蚭定に切り替えはあらかじめMakefile内に蚘述しおおきたす。 Makefileの甚意を甚意しおおくず、チヌム内にコマンドの共有ができるのず、CI 䞊で䜕かあったずきに手元での怜蚌がしやすくなるので䟿利です。 .PHONY: build test local-run local-up dev-deploy build: sam build # テストの実行 test: @cd ./hello-world/ && \ go test -v ./... # ロヌカルでlambdaを実行する local-run: build sam local invoke \ --parameter-overrides 'ENV=local AppName=Hello' # apiずしお起動する堎合 local-up: build sam local start-api \ --parameter-overrides 'ENV=local AppName=Hello' # デプロむする dev-deploy: build sam deploy \ --s3-bucket sam-app-stack \ --parameter-overrides 'ENV=dev AppName=Hello' \ --force-upload \ --no-fail-on-empty-changeset たずめ AWS SAM を䜿った入門ず運甚蚭定の䞀郚を玹介したした。 もしこれから AWS SAM を䜿甚される方々の助けになれれば幞いです。 埓来の郜床deployしお確かめる方法だずどうしおも1回の怜蚌に時間がかかっおしたい、Lambdaに手を出しづらい状況䞋だったので、今埌の量産䜓制に無事に繋げられそうです。 バヌゞョン1 になったこずにより倧分扱いやすくなった印象をうけたした。 たた、今回は時間の関係で導入たではできおないのですが local stack を䜿えばAWSリ゜ヌス䟝存のテストもできそうなので、機䌚があればこちらも挑戊しおみたいず思いたす。