2021-09-21のツイート
- 02:59:45
computed演算子はstateの中でまとめる。 - 03:00:50
reactiveをtoRefsとスプレッド構文でref関数と同じアクセスができる。 - 03:09:20
Composition API の propsの型定義。 user { type: Object as PropType} Propsの型をジェネリクスで指定できるところがポイント。 - 03:23:00
Che Router のhashモードは歴的理由で残されている。昔は、「#」以降のフラグメント識別子が変更されてもブラウザはHTTP要求をださないという仕様になっていた。ブラウザがリフレッシュされないのでJavaScriptで完全に制御できる。 - 03:26:32
プラグイン化することですべてのコンポーネントで使用できる。 - 03:44:45
スコープ付きスロットで親コンポーネントにアクセスさせるプロパティを指定できる。 - 03:47:02
複数のスロットを定義するにはtemplate要素で囲みv-slotディレクティブでスロット名を指定する。 - 03:49:54
veevalidateでバリデーションを簡単に実装できる。 - 03:58:00
Propsはvalidatorでバリデーションできる。 - 12:40:21
バケットポリシーはアカウント、バケット、オブジェクト単位、IPアドレス単位のアクセスポリシー。IAMユーザーごとのアクセスはIAMで設定する。バケットポリシーが設定されていなくてもIAMポリシーで許可していればアクセスできる。
2021-09-19のツイート
- 21:05:45
compositionAPIのsetup内で初期化した変数はbeforeMountの初期化と同じ。onMountedで必要な変数はsetup内で初期化すること。
2021-09-16のツイート
- 13:38:20
トレンドにキャッチアップできない恐怖心はあるけど基本に忠実でありたい。結局新しい技術も元をたどれば古典的な問題への解決策。 - 14:13:31
Nuxt.js、Amplify、Graphqlの組み合わせでがいいかも。
Airbnb ホテル予約システムデザインから学ぶ設計
概要
Airbnb ホテル予約システムデザインについての記事を見つけた。 面接時に問われる典型的なシステムデザイン問題らしい。
限られた時間で答えなければならないため余計な情報がない。 効率的な設計手順や原則について学べると思う。
設計の手順
以下の順番で設計する。
- 機能要件と非機能要件を明確にする
- テーブル設計をする
- API 設計をする
- API をマイクロサービスに分割する
- 高次元のアーキテクチャ図をかく
- アクターごとのエンドツーエンドフローを整理する
- マイクロサービスごとの責務を整理する
- 主要なシステム(今回の場合ホテル予約機能)のワークフローを整理する
機能要件と非機能要件の書き方
Hotel Manager
1. Actor should be able to register Hotel on the platform
2. Actor should be able to add/update/delete Room Types in the Hotel
3. Actor should be able to add/update/delete Room of given Room Type
4. Actor should be able to define the price and inventory of room types on daily basis
Customer
1. Actor should be able to search available hotels by city, check-in, check-out date
2. Actor should be able to select a hotel and see all the available hotel types and their prices
3. Actor should be able to select the desired room type and proceed for the booking
4. Actor should receive the notification about the booking details once the booking is completed
上記は記事から機能要件を抜粋したもの。
アクター単位で機能要件を羅列している。
日本語だと、「A(アクター)が~(機能)をできる」という書き方になるだろう。
Non Functional Requirement
1. System handling operations related to Hotel Managers and booking flows should be Highly Consistent
2. Discovery Platform showing hotels to the customers should be Highly Available
3. System should have low latency
4. System should be Highly Scalable with increase in number of restaurants and customers
5. System should be able to handle concurrent requests such that no two customers should be able to book the same room on a particular day
次は非機能要件。
データの整合性、可用性、レイテンシー、スケーラビリティ、同時要求に対するハンドリング などについて問われている。
これらはマイクロサービスにおいては特に重要なポイントになる。
テーブル設計
テーブル設計は主キーと外部キーを定義してテーブル間の関係を明確にすること。
実際どういう値が必要になるかは機能要件だけではわからないことが多いが、まず最低限のデータを洗い出す方が効率的。
API 設計とマイクロサービス分割
HTTP リクエストと URI を設計する。
これらがマイクサービスに分割される。
1,2,3 がホテル管理サービス
4,5 が検索サービス
6,9,10 が予約サービス
7,8 が予約履歴サービス
高次元のアーキテクチャ
アクターとマイクサービス、マイクサービスをつなぐプロセス間通信、キャッシング、DBクラスタ、分散DBなどに言及している。
サービス間の通信は基本は王道の非同期メッセージング。
検索には Elastic Search のインデックス機能を採用。
データ容量が大きくなりがちな履歴情報はアーカイブシステムから分散DBで処理。
2021-09-11のツイート
- 04:37:32
Atomic Design のデータフローを考える。1ページに1責務。テンプレートは生体の集合。ビジネスロジックは生体が持つ。1つの責務を果たすために複数の生体で共有するストアはテンプレートから渡す。ストアが持つデータはページの責務を反映する。責務外のデータをもたいないこと。 - 20:48:48
Lambdaのセキュリティベストプラクティス。 関数ごとのにIAMロールは一つ。IAMロールを関数間で使い回さない。たとえば、AWS KMS キーへのアクセスを要する関数の IAM ロールを複数の Lam bda 関数で共有したとすると、その後、共有した関数のすべてが同一の暗号化キー へのアクセス権を持ってしまう。 - 21:05:22
Lamndaのアンチパターン。 Lambda Monolithic。 複数のエンドポイントを処理するハンドラーを作成しないこと。エンドポイントごとにhandlerを作ること。
CIDR
CIDR とは
「Classless Inter-Domain Routing」の略。サイダーと読みます。CIDRは、ク ラスを使わないIPアドレスの割り当てと、経路情報の集成を行う技術です。ク ラスとは、IPアドレスのネットワーク部とホスト部を決められたブロック単位 で区切る方法で、簡単ですがアドレス空間の利用に無駄が生じてしまいます。 これに対しクラスを使わないCIDRでは、任意のブロック単位で区切ることがで きるため、IPアドレス空間を効率的に利用することができます。
なぜ必要か
AWS の文脈では VPC を論理的ネットワークで区切ったサブネットを定義するために必要。
いつ使われるか
VPC を作成するとき。
どうやって使われるか
サブネットマスクからAWSに予約されたアドレスを除いた、利用可能なIPアドレスを算出する。
例1)
Network 198.168.0.0
/16 Subnet Mask 255.255.0.0
使用可能IPアドレス
32 - 16 = 16 hosts bits = 65536addresses
から
AWS で予約されたアドレス
192.168.0.0. Network address
192.168.255.255 Broadcast address
を除く
192.168.0.1 ~ 192.168.255.254
例2)
Network 198.168.0.0
/20 Subnet Mask 255.255.0.0
使用可能IPアドレス
32 - 20 = 12 hosts bits = 4096 addresses
から
AWS で予約されたアドレス
192.168.0.0. Network address
192.168.15.255 Broadcast address
を除く
192.168.0.1 ~ 192.168.15.254
192.168.15.255 の 15 の計算方法
/20 だから 8 + 8 + 4
24 = 16
0から始まるから最大で15
CIDR のルール
CIDR Block は /16 から /28 まで
VPC 内に存在するどの CIDR とも重複してはいけない
RFC 1918 に従うプライベートIPアドレスの範囲を指定すること
クラスA 10.0.0.0～10.255.255.255 （10.0.0.0/8）
クラスB 172.16.0.0～172.31.255.255 （172.16.0.0/12）
クラスC 192.168.0.0～192.168.255.255 （192.168.0.0/16)
