岩﨑LT資料

Transcript

1. serverlessアーキテクチャをキャッチアップすることは 成⻑につながる？ 株式会社 エニキャリ 開発統括 岩崎⼤輔
2. ⾃⼰紹介 2004年4⽉ 株式会社ワークスアプリケーションズ⼊社 ・⼤企業向け基幹業務パッケージの⼈事給与部⾨の新規機能要件定義および開発 ・ECサイトパッケージの新規機能要件定義およびECサイトの運⽤ -> ⼩規模チーム（8⼈）のエンジニアリーダーとして活動 2016年2⽉ WEB系フリーランスエンジニアとして活動 ・事業会社の、ビジネス検証⽤のプロダクト⽴ち上げをメインに活動 2019年10⽉ 株式会社エニキャリにテックリードとして参加 ・エニキャリのシステム基盤、プロダクトの⽴ち上げ、実装運⽤を担当 ・開発チームビルディング、採⽤ 2020年8⽉ 株式会社エニキャリ開発統括執⾏役員
3. 構成 ▪前半 タイプごとに分かれるソフトウェアエンジニア。リーダーになるため共通して⾝ につけたい視点。 ▪後半 エニキャリ事例としてserverlessアーキテクチャで プロダクトの実装＆運⽤してみた。 Serverlessプロダクトをキャッチアップすることは、成⻑につながるか。
4. ▪ 特定分野コミットタイプ（研究者） ・その分野においての成果を出すことがミッション ・スキルツリーが独⽴している技能 （ex 機械学習、AI、セキュリティ、ネットワーク） ▪ プロダクト・プロジェクトコミットタイプ（実務家） ・⾃社プロダクト開発 / SIプロジェクト等、 プロジェクト単位を成功させることがミッション ・full stack/ backend/ frontend engineer （プロダクトのための広範囲知識） ・TechLead / CTO タイプごとに分かれる、ソフトウェアエンジニアとしての強くしたい分野
5. タイプごとに分かれる、ソフトウェアエンジニアとしての強くしたい分野 ▪ 特定分野コミットタイプ（研究者） ・専⾨分野の深化 → 正直… 後半戦はミスマッチかも… ▪ プロダクト・プロジェクト コミットタイプ（実務家） ・ソフトウェア関連分野での継続的な学習 → 後半戦、serverless分野について知⾒を共有 両タイプ共に、リーダーになるためには、チームの動きの視点が必要。 結局はチームの中で⾃分の対⼈コミュニケーションにどれくらい戦略的になれるか。
6. タイプごとに分かれる、ソフトウェアエンジニアとしての強くしたい分野 ▪ おすすめ図書 (PPHMFͷιϑτ΢ΣΞΤϯδχΞϦϯά ʕ࣋ଓՄೳͳϓϩάϥϛϯάΛࢧ͑Δٕज़ɺจԽɺϓϩηε チームに関連するのは、第2章から第6章 特に、視点を逆転して読んでみるといいかも。 リーダーになるためではなくて、今の開発チームリーダーは何を考え ているかを逆算するためのツールとして。 ・上司としてチームリーダーは何を考えてマネジメントしているのか。 ・彼らの考える理想的な状態を理解し、その実現を助けているメン バーに⾃分はなっているか。 ・彼らの決断はチームにとって、いい決断なのか悪いのか。何でそう なったのか、⾃分だったらどうするか。 敵に勝つには、敵を知るべし。
7. 後半戦 エニキャリ事例としてserverlessアーキテクチャで プロダクトの実装＆運⽤してみた。 Serverlessプロダクトをキャッチアップすることは、成⻑に つながるか。
8. serverlessアーキテクチャでプロダクトの実装＆運⽤してみた。 -> 2019年10⽉ 株式会社エニキャリにテックリードとして参加 ・ミッション!! UberEatsみたいなプロダクト全般( 配達員アプリ・店舗アプリ・オペ レータ⽤サービス）をなる早で使える様にしたい。 もちろん、セキュリティなどは疎かにせず、将来的な規模拡⼤にも対応し たい。 創業直後ゆえ、開発メンバーはごく少数(私含め2名） なんとかやってみるしかない…
9. serverlessアーキテクチャでプロダクトの実装＆運⽤してみた。 ▪半年ぐらいで何とかなりました。 店舗⽤タブレットアプリ 配達員アプリ ADMS（エニキャリデリバリーマネジメントシステム）
10. serverlessアーキテクチャでプロダクトの実装＆運⽤してみた。 ▪何とかするには。 → ⾝を軽くしかない。（=作る範囲・責任範囲を限定する） ・インターネットのAPIは AWS API-Gateway ・RDSは Aurora RDS ・サーバーバックエンドはlambda/TypeScript ・WEBサービス周りは AWS ECS /Rails ・モバイルアプリのバックエンドはFirebase ほとんどで、エニキャリ側でサーバーを持たない。 インフラ構築とサーバ運⽤の負荷は、AWS/GCP側に委任する。 セキュリティは境界部分を考えれば良い。
11. serverlessアーキテクチャでプロダクトの実装＆運⽤してみた。
12. serverlessアーキテクチャでプロダクトの実装＆運⽤してみた。 ▪ 外部からのデリバリー依頼のAPI呼び出し例 時間がかかる処理は AWSのメッセージ キューサービスに格納 Lambdaによって、イベント発⾏し （配達依頼作成完了した時等) そのイベントに対応する別lambdaが 実⾏されたりする
13. serverlessアーキテクチャでプロダクトの実装＆運⽤してみた。 ▪ 外部からのデリバリー依頼のAPI呼び出し例 ・ API の呼び出し数がいきなり2倍になっても ・ lambdaの起動数が増えるだけ。
14. serverlessアーキテクチャでプロダクトの実装＆運⽤してみた。 メリット デメリット ・スパイク時のリソース調整も容易。 ・インスタンスやコードが起動毎にリフレッシュさ れる。 ・動いているプログラムのトラブルが⾮常に少な くなる。 ・コード改変のリスクが少なくなる ・バッチ適⽤等の運⽤メンテナンスの⼿間を少なく する事ができる。 ・ほとんど従量課⾦なので安価。 ・プロダクト⽴ち上げの実装期間が⾮常に短くでき る。 ・lambdaなどのデプロイには、特殊なデプロイプ ロセスが必要。 (AWS サーバーレスアプリケーションモデル (SAM、 Serverless Application Model) ツールを使ってデプ ロイ) ・⼀連の業務フローのテストで、AWS環境が必要 になりテストしにくい。 ・機能開発の前提知識に、AWSのserverlessサービ スの基礎知識（インフラ初級レベル）が必要になる。 ・AWS障害時、再開までは祈るだけ。 ▪サーバーレスをメインで利⽤する事のメリット・デメリット 運⽤メンテナンスの楽さ vs 開発体制の構築の⼿間
15. serverlessアーキテクチャでプロダクトの実装＆運⽤してみた。 ▪まとめ ・For full stack/ backend/ frontend engineer 今後のプロダクトのシステム基盤の⼀部から全部が serverlessと呼ばられる仕組みを利⽤する様になる。 ・For TechLead / CTO 志望 新プロダクトの⽴ち上げの実装スピードや、運⽤⾯で省コスト体質になるメリッ トを⼤きい。
16. serverlessアーキテクチャでプロダクトの実装＆運⽤してみた。 ▪まとめ ぜひ、シンプルなWEBサービス（例：twitterもどき）をserverlessの仕組みで作っ てみることをおすすめします。 serverlessアーキテクチャを構築するには、ネットワーク・セキュリティ周りの全般 知識は必要ですが、専⾨家レベルまでは要求されない AWSの参考資料でキャッチアップは可能。