00:03
というわけで、LayerX NOW!第4回です。
実はですね、前回ちょっと音が悪かったので、もう一回きれいに撮り直してみようかということで、
第4回は今回、もう一回撮り直しをしながら、高江さんとお話をしていきたいと思います。
よろしくお願いします。
改めてですね、LayerX NOW!なんですけども、この番組の趣旨は、
まずLayerXの技術チームについて、皆さんに知っていただきたいなというところが目になってまして、
今回は前回に引き続いて高江さんに来ていただいております。
この守護神高江さんにですね、今回はLayerXインボイスに関連して、
インフラの話とかをAWS Summitで知っていただいたということなので、
ちょっとこの技術ネタをいろいろ掘っていこうかなと思うので、よろしくお願いします。
よろしくお願いします。
今回AWS Summit、5月ですよね、実際に配信されるのは。
どういったお話をしてきたのかなというのをまずかいつまんで、
一応いただいてもいいですか。
まず発表の内容としては、LayerXインボイスを4ヶ月ほどでコンセプトを立ち上げたところからリリースまで
持っていたんですけど、短期間で高速に開発するために、
主にインフラの視点でどういうことを考えてやったかっていうところを
ダイジェストというか、ポイントを押さえてご紹介している内容になります。
実際にLayerXインボイスって、インボイスもですし今動いているワークフローも
とにかく爆速開発ってやってきてるじゃないですか。
この爆速開発、すごいこの中身をAWS Summitの中でお話ししていただいたと思うので、
そこはSummitで聞いていただきたいなというところではあるんですけど、
少しだけ内容をちらみせて聞いてみたいのが、特にこのインフラの話、
どこにフォーカスを当ててお話しした感じだったんですか。
そうですね、まず第一にあったのはとにかくスピード重視ということで、
あとチームの開発の人数がそれほど多いというわけではないので、
いかに本質的にやらないといけないことにフォーカスして、
それ以外のところは巨人の肩に乗る的な意味で、
AWSのマネージドサービスとかをうまく使って、
いかにやらないといけないんだけど本質じゃないところというのはお任せして、
本来自分たちがやらないといけないインボイスのアプリケーションというかコアロジックの部分
というところに集中できるような体制づくりだったりアーキテクチャだったり、
実際の実装だったりというところを注意しながら進めたという感じですね。
結構トレードオフをスピードに振り切った話ですね。
このスピード振り切るというのとインフラの守らなきゃいけないと結構矛盾するじゃないですか。
相矛盾するこの2つに、勝手に守護神と呼んでましたけど、
03:01
守護神としてはどういう風に工夫を加えていったのかとか聞いてもいいですか。
そうですね、まずやっぱりアーキテクチャを考える上でマネージドサービスをうまく活用する
というのが第一のポイントになるんですけど、それ以外さっきおっしゃったように
主にセキュリティとかですね、請求書をお預かりするというところで
かなり機密性の高いものを管理することになるので、
セキュリティは当初からかなり重視してはいましたと。
その中で弊社の他のインフラというかセキュリティとかインフラを見ているエンジニアとも相談しながら
細かいところを詰めていって、スピードを重視するんだけど決してそのインフラを雑にはしないと。
ちゃんと閉めるべきところは閉めて、セキュリティを確保した上でスピードをいかに出すか
というところがポイントになってくるかなという感じですね。
そこはかなり気を使いながら作っていったつもりです。
今ぶっちゃけすごい難しいことを言っているなと思ったんですよ。
多分これ聞いている人たち、分かるけどどうすればいいんだろうみたいな
閉めるとこってどこなんだろうみたいな話になると思うんで
特にどういうところを閉めるみたいな話ですか?
そうですね、やっぱりざっくりカテゴリーで分けると
データと通信路の暗号化というところと、あとは変更の管理というか
例えばインフラを変更しましたというときに誰がどういう目的で
具体的に何をどう変更したのかみたいなところをきちんとトラッキングできるようにだったりとか
あと基本的なことなんですけど、変更権限とか
例えばアプリケーションの実行権限とかを最低限に絞って
本来関係ないところにデータにアクセスできちゃったとか
そういったことがないように、例えばAWSのIAMであれば
アクションとかリソースを本当に最低限必要な部分だけに絞るとか
あとAWSのマネジメントコンソールにアクセスするときの
SSO、IDパスワードじゃなくてSSOにするとか
そのSSOの権限も必要な人だけに付与するみたいな形で
とにかく権限管理というのはかなり厳密にやっていきましたね。
ということは誰が何をできるかを明確にするところから
ロジック的な安全性もだけど、それよりもまずは
外からいたずらされない環境に
運用でうまくカバーしましょうというところもありつつ
可能であればシステムレベルで原理的にできないようにする
みたいなところをまずはできるところからやっていったという感じですね
どうしてもそこでやろうとするとあまりにもコストかかりすぎて
ちょっとコスパ合わないなというところは運用でカバーとか
そういった判断を重ねていったという感じですね
結構その辺の巨人の肩に乗るというか、IAMセキュリティグループだったり
ちゃんとSFBS使おうみたいな話から
そこを自分たちが作らずみんなが運用できるように
そうですね
これを正直メンバーがたくさんいて
06:01
もささんからも話を聞いていると
みんなインフラにもコミットしたりとか
その中でみんなが開発していくと
やっぱり穴が出るのってその辺だったりするじゃないですか
これはどうやって防いでるか
そうですね、インフラに関しては少なくとも
私以外の誰かが手を入れるという時は
テレビ局のレビューとかを回してくれて
きちんと確認した上でやるということで
まず一つはちゃんとレビューを通すというところが一つと
あとはそういったアプリケーションエンジニアが
インフラに手を入れるという時って
そんなにがっつり手を入れるというわけではなくて
結構軽微なものが多いと
例えばS3のバケットを新しいのを作りたいとか
ダイナモテーブルを新しいのを作りたいみたいな形で
今もう既に、例えばテレフォームで形があるところ
コードがあるところにちょっと追加するみたいなケースがほとんどなので
そういったところはテンプレーというかスニッペットというか
シュッと作れるように最初にあらかじめコード化しておいて
新しいのを作りたい場合は
まず既存のリソースの定義の部分をコピーして
そこで名前変えるなり何なりというので
簡単に位置から考えながら作っていくというのが
発生しないように
最初にある程度例を作っているところは結構大事かなという感じです
再利用できるというのを前提に
いろいろリソース定義とかをしていくという感じです
コードで再利用できるようにするという感じですよね
テレフォームですね
多分各事業部みんなテレフォームを作っている感じですね
そうですね
そういった形で
もし新しいリソースを作るにしても
名前ぐらい入れれば終わるよみたいな
そんな世界にして
そうやってみんなが変な穴を開けないようにする
よくある流出事件だとS3のマーケット
フルオープンによくありますからね
テレフォームのモジュール単位でも
規定を出しているということですか
今はテレフォームモジュールはまだ定義していなくて
すごいシンプルに
テレフォーム用のプロジェクトのリポジトリをGitHubに作ったら
そこにTFファイルをフラットに置くという形で
必要なリソースごとに定義しているという感じなので
今まだモジュールを使った複雑な再利用を
がっつりやるという構成ではなくて
今の再利用はモジュールとして再利用というよりも
コードをコピペして再利用みたいな形になっています
モジュール化とかもう少し規模が大きくなって
再利用可能な範囲という
いい区切りみたいな形が見えてきたら
着手かなという感じですね
再利用しやすいパーツになればなるほど
開発コストが高い
そこのバランスを取っている
今コストの話をしたんですけど
どうしてもトレードオフでスピードを取ったり
いろんなトレードオフを取る中でコストって結構
09:02
劣化するってことになるじゃないですか
とはいえ僕らスタートアップじゃないですか
すごいこの会社は面白いな
みんな意外と1000円単位100円単位もケチるじゃないですか
そういうところに対してインフラとしては
大まかなコンセプトとしては
もちろんコストはなるべく
できる限り抑えていきたいとは思っているんですが
最初からあまり最適化しすぎないっていうところは
結構大事かなと思っていて
AWSでコスト最適化ってなると
まず一番に思い浮かぶのがセービングスプランとか
リザーブドインスタンスとかだと思うんですけど
これも例えばエラステキャッシュとかを
リザーブドインスタンス化したいってなった場合に
使うのをやめるっていうことも随分あって
例えばわれわれのインプレスのケースだと
最初ジョブをサーバーとワーカーの間で
メッセージングするときに
メッセージキューとしてレディスを使ってたんですけど
それがその後SQSに変わったりとかで
結構リソースレベルで何を使うかっていうのが
その時その時のアプリの特性とか要件によって変わってくるので
最初から半年とか1年とかで
コストを決めてしまう
リザーブドインスタンスみたいなのは
ちょっと最初は入れないと
ただその代わりECSとかはスペックを落としてだったりとか
開発環境だったらマルチエーゼットやめるとか
あと使ってないインスタンスは普段は落とすとか
そういった地道なコスト削減というので
頑張るという感じですね
将来的に渡ってかかるようなコストというのは
あんまり最初からはさかない
ただ今日は明日でできるところというのはやるという感じですね
結構重量課金系のものを使うことも多いですよね
そうですね
より粒度の小さい重量課金系で
意外とコストに跳ねるのはその辺だったりしますか
そうですね
常時動いてるで取られるもの
RDSだったりとかECSだったりとか
地味なところでVPCのNATゲートウェイとか
そういうところが結構効いてくるので
NATゲートウェイも数減らしたりとかそういう感じですかね
さっきのエラスティキャッシュの話とかも
エラスティキャッシュ立てっぱなしよりSQSの方が
リクエスト数に対して考えられやすいよね
ここはもうアーキテクチャで解決できる部分は取っちゃう
そういう意味では結構
巨人の硬い能力的なところだと
ECSファーゲートの活用が多いですよね
そうですね
世の中の潮流的には
Kubernetes使おうやみたいな話が多いじゃないですか
僕も全職とか色んなコミュニティとかで
どっちがいいんだっけみたいな話をするんですけど
僕も実は結構ECSとか薄いやつ使いたい方なんですけど
LayerXとしてはどういう経緯で
12:02
この技術スタッフについていたんですか
そうですね
まず最初の設計の段階で
ファーゲートかKubernetesかってなった時に
Kubernetesやっぱり管理が重いっていうイメージがあって
実際にインボイスでKubernetesを管理していたわけではないので
あくまで主観というか想像なんですけど
使っていくにつれやっぱり辛くなるだろうな
っていうのはあって
プラス0.5人分くらいっていう感じだったんで
それでKubernetes以外に他にも色々メンテナンスしないといけない
リソースだったりとか
監視系も設定しないといけないとかっていう中で
ちょっとそこの1コンポーネントの部分で
あんまりガッツリコスト取られるのは
ちょっとしんどいなというのがあって
その分ファーゲートはタスク定義とサービス作っておけば
あとは吉谷にスケーリングとかやってくれるので
そういうところも含めてかなり
やらないといけないんだけど本質じゃない部分というところを
うまくAWS側が吸収してくれるというところで
今はファーゲートにかなり頼ってますね
なので最初からKubernetesやろうかみたいな話は全然なくて
もうファーゲートでいいよねぐらいの感じでスッと決まったという感じですね
結構いい話ですね
チームの意思決定軸が揃っているから
それは結構ありますね
技術選択意外とすんなり決まっているケースが多いですね
そうですね
みんな同じような経験をしていて
いろいろ挑戦して反省とかも含めて
じゃあ次はこうしようというのがあって
それが結構揃っているチームなのかなという感じですね
なのでちょっと話変わってマイクロサービスとかの話になるんですけど
マイクロサービスとかも多分
ゆくゆくは避けられないかなと思うんですけど
マイクロサービスとかはそういうのなくてモノリスでいいよねとか
というところも結構意識が揃っていたので
そういう意味では開発チームのこういう風にやればいいんじゃないのって思っている
イメージみたいなのはかなり近い
みんな近いイメージを持っているんじゃないかなという感じですね
意思決定軸とか考え方を揃えることで
技術スタックもすんなり揃っていくみたいな
そういうところのメリットが爆速につながっているんですね
そうですね
インボイスの中にあったユーザー管理とか
ID管理みたいなところを切り出して
独立したサービスにしましたという時に
ほとんどインボイスの中の
構成とか実装とかというのが使い回しができたので
インボイスを立ち上げる時に比べて
IDとかユーザー管理の部分はかなり短期間で
インフラ含めてできたかなと思っていて
その後ワークフローのサービスというか機能を作ったんですけど
そこもインボイスとIDで培った
ストップした技術的な資産を
上手く使うことでかなり短期間で
構築できたかなと思うので
みんなが大体同じような作りをしているので
15:01
再利用とか横の展開とかが
スムーズにできるというのもあるので
そういう考え方を合わせるだけじゃなくて
実装レベルでもなるべく合わせる
同じようなスタイルでやるということで
横展しやすいのは生まれるかなと思います
そうやってAXワークフローの爆速開発が成り立ったわけですかね
あれはかなり爆速でしたね
それはインボイスとかID基盤のところで培った
インフラの行動をそのままパツッと持ってきて
インフラはほぼ流用という感じで
それなりにフロントエンドあって
バックエンドあってという構成なんですけど
1.5日から2日くらいで構築できたので
それはもう実際にインボイスの再利用というか
使える部分が多かった
意図してそういう風に作ったんですけど
そういうのがあってかなり早く短期間で
立ち上げられたという感じですね
今こうやってECSに振り切って
マネージドのものに振り切って
一定限の対策で作れるようにしよう
この先考えてることってあるんですか
リソースというかAWSに関しては
当面は今の方針が続くかなと思っていて
しばらくはAWSさんのマネージド
特にフルマネージドに近いサービスを
積極的に使っていくことになるかなと
なので自分たちでKubernetesをガリガリ
メンテしていくみたいなのは
その必要性が出てくるまではという感じですね
一方で監視の部分
ログの管理だったりとか
サービスでちゃんと動いてますよねという監視だったりとか
そういうところがまだまだ不十分かなと思っていて
最低限のことはやってるんですけど
まだまだやりたいことはできなくて
例えばフロントエンドからバックエンドAPI
データベースとかアトロードバランサーとか
流れてユーザーに戻るまでに関わる
一連のリソース全部のログとかを集約するみたいな
そういうところはまだ現状できてないので
その辺これからの課題というかやらないといけないことかな
という感じですね
最低限の監視からもうちょっと
発展的な監視体制を組んでいくというところが
当面の課題ですね
分散トレーシングとか
あのダッシュボード出来上がるだけで僕はテンションが上がる
大事ですねあれ
障害とかが起きた時にどこが生きてどこが死んでるんだっけ
パッと把握しようとするとダッシュボード非常に大事なので
あの辺は
何でしょうね可視化されていいだけ以上の効果があるから
トラブルシュートを少ない人数で
迅速に障害対応するという上で早急に
その原因を究明するという意味でも非常に大事な
パーツになるかなという感じですね
監視を丁寧にやることでチームの改善も
18:02
スピードが上がられて
あとは何か起きた時にダメージを最小化できる
大事なとこですよねモニタリング
これからこの前は障害なんかも踏まえて
強化していきたいところですね
というところで我々のインフラの話を今日はしてきたわけですけど
最後にですね
来週4月27日にイベントがあるということで
そこら辺の宣伝だけして終わりましょうか
AWSサミットの前哨戦というかあれなんですけど
サミットの内容と若干被らせて
事前のイベントということで登壇させていただきますと
AWSさんのスタートアップコミュニティという
コンパスのグループがあるんですけど
そちらの方からのご招待いただいて登壇させていただきます
内容としてはAWSサミットでは
今現在AXインボイスこういうインフラ構成になってますよ
というのをご説明するんですけど
今回の4月27日のイベントでは
そこに至るまでの立ち上げ機器からのインフラの変遷
みたいな形で時系列で最初こういうところからスタートして
こういう意思決定が合間にあって
こういう感じでインフラの構成形を変えていきましたよ
というその時その時我々が何を考えて
どういう意思決定をして結果どういうアキテクチャになったか
みたいなのをちょっとずつサービスというか
インフラが大きくなっていく
移り変わりみたいなのをお話できればなと思っています
はい楽しみですね
ぜひぜひ皆さんご覧ください
ぜひ皆さん聞いてくださいという感じで
というわけでレイアエックスナウ第4回はですね
高井さんにインフラのお話をしていただきましたというところで
一旦以上とさせていただこうかなと思います
ありがとうございました
