こんにちは、株式会社LIFULLでエンジニアをしている塩澤です! 今回は、2020年1月28日(火)に開催した、『Ltech#10 不動産・住宅情報サイト「LIFULL HOME'S」の中の人が語るAWS活用前線』についてレポートします!
Ltechとは
Ltech(エルテック)とは、LIFULLがお送りする、技術欲をFULLにするイベントです。 特定の技術に偏らず、様々な技術の話を展開していく予定です。 今回でなんと、#10です!! 祝二桁開催!!
不動産・住宅情報サイト「LIFULL HOME'S」の中の人が語るAWS活用前線
記念すべき二桁開催となる今回のテーマは、『不動産・住宅情報サイト「LIFULL HOME'S」の中の人が語るAWS活用前線』です。 部署を問わず、様々な活用事例を話してもらいました!
それでは各発表のレポートです。
Fargate/CloudWatch Eventsでバッチをサクサク作った話
www.slideshare.net
最初のLTは、LIFULLで動いているバッチの環境を改善したお話です。
LIFULLでは、日次バッチと不定期なイベント駆動のバッチが動いており、かつ利用するAPIのリポジトリにバッチ処理が同居している状況でした。 リポジトリにはこれ以上バッチを追加したくない...
それを解決するために、FargateとCloudWatch Eventsを利用してバッチを起動する構成を組むことにしました。 結果として、APIとバッチのリポジトリが疎結合になることでメンテナンス性がアップし、バッチ用サーバの管理から解放されることに!
社内通貨のシステム構成
www.slideshare.net
続きまして、LIFULL社内で開発している社内通貨「LIFULL COIN」をAWS上に構築したお話です。 LIFULL COINでは、Quorumというエンタープライズ向けのブロックチェーン基盤を利用しています。
このブロックチェーンのノードの起動と停止をAWSをつかって実装しました! FargateのタスクでQuorumノードの起動・停止イベントをAWS EventBridgeに送信し、紐つけられたStep Functions Express Workflowsによって各種処理が実行される構成となっています。
自分はExpress Workflowsに触ってみたくなりました。
CloudFormation による LIFULL HOME'Sサイト問い合わせ情報登録APIの構築と管理
www.slideshare.net
ここからは、LTではなく15分の発表となります。 まずはCloudFormationを使った、APIの構築と管理についてです。
SalesforceというCRMツールに情報を登録するためのAPIを作成する際に、全てのリソースをCloudFormationを使って構築・管理したお話です。 CloudFormationはリソースの設定や情報をコードで管理できかつ、そのコードから自動でリソースを作成してくれるサービスです。
APIの新規開発に当たって、手作業の運用コストの削減、環境の冪等性の確保、構成管理の属人化の防止などを目的としてCloudFormationの採用を決定しました。
CloudFormationのコード1つで全てを管理することもできましたが、APIの全てのリソースを管理するとなると肥大化しメンテナンス性の悪さを招いてしまうため、機能単位でテンプレートを分ける設計にしました。 また、あえてCloudFormationで管理しない部分も考慮する必要がありました。
最終的には、CloudFormationで全てのリソースが管理できるようになりました。 これによって、手作業の設定によるカオスな状態に陥ることなく、誰でも同じ環境を整える状態になりました。
このお話は自分も少しだけ関わっている(すでにCloudFormationで環境構築ができる状態でJoinしたので楽でした)ので、改めてCloudFormationのありがたさを感じました。
LIFULL HOME'S ネイティブアプリ用APIのデプロイを自動化する
www.slideshare.net
次は、ネイティブアプリ用APIのデプロイを自動化したお話の予定でしたが、自動化しようとして失敗したお話になります。 最終的には成功?しているのでご安心を!
今回のお話の対象となるAPIでは、個人環境で実行しているデプロイ用のスクリプトの複雑化や、個人環境への依存度の高さなどが課題となっていました。 そこで、AWSの各種サービスを駆使してデプロイを完全自動化を試みることに。
方針としては、GithubへのソースpushをトリガにSAMとCodePipelineなどを利用してデプロイフローを組むことにしました。 しかし、そこにはいくつもの壁が...
Parameter StoreとLambdaを使った環境変数の取得処理の際に、都度発生してしまう通信をうまいこと回避する必要がありました。 同じAPI Gateway IDができてしまう問題。LambdaのエイリアスとAPI Gatewayのステージが上書きされてしまう。 それらを乗り越えた先に待ち受けた最大の壁は「既存のパスを消さないと違うテンプレートからデプロイできない」というものでした。 SAM template を独立させておく必要があったため起こってしまった問題です。
結果、Github Actions を使って自動化することに。 SAMにも限界があること、AWSで完結させる以外の選択肢もあるとのことでした。 失敗することが1番学びに繋がるかもしれませんね。
LIFULL HOME'S のAWSアカウントに SavingsPlans を導入した話
www.slideshare.net
いよいよトリです! 最後はLIFULL HOME'SのAWSアカウントにSavingsPlansを導入したお話です。
AWSで一番気になるところはやっぱりお金についてですよね。 SavingsPlans (SPs) はリザーブドインスタンス(RI)に代わる新しい料金プランです。 このSPsの導入についての発表となります。
SPsを利用したコスト最適化の第一歩目は、「SPs」を理解することです。 割引率は?適用される範囲は?インスタンスタイプによる違いは? 最適なプランを選ぶためにもまずは理解することから始めましょう。
次にプランの選択です。 コスト最適化の適用範囲が広ければ、割引率は下がってしまいます。 このトレードオフを考えて選びましょう。
そして、コミット金額を決めること。 今回は、Cost Explorerを利用した見積もりとCost Usages and Report (CUR) + Athena + Solverを利用した見積もりについて詳しく聞けました。 Athenaで出力したコストレポートに対してSolverというツールでコミット金額を算出します。 書ききれませんので、詳細についてはぜひ資料をご確認ください!
導入してどうなったかといえば、インスタンスタイプに関わらず最適化がなされ、割引率も高くなりました。 また、使いきれなかったコミット金額が発生したものの、他のアカウントに適用されることで無駄にはなりませんでした。
結論、SPsは神プランだった。とのことです。
懇親会の様子
最後に、登壇者と参加者の方を交えた懇親会です。
最後に
Ltech では、LIFULLエンジニアが中心となって皆様の技術欲を満たすよう実例を交えた勉強会を開催しています。
今後もLtechを積極的に開催していきますので、 ぜひ気になった方は、connpassでLIFULLのメンバー登録をよろしくお願いします!