お久しぶりです、小とろです。
ここ半年のプロジェクトで色々新しいことに集中していたので、全然アウトプットができていませんでした...
ちょっと自分の振り返りも兼ねて、この場で書き出していこうかと思います。
具体的な案件内容は伏せて、どんなものを使って開発をやっていたかを書いていきます。
はじめに
この記事は富士通株式会社FSWebユニット(旧富士通システムズウェブテクノロジー)が企画する
いのべこ夏休みアドベントカレンダー 2021の5日目の記事です。
本記事の掲載内容は私自身の見解であり、所属する組織を代表するものではありません。
学んだことのリストアップ
ひとまず何があったか全体を見るために、一通り書き出してみました。
書き出した項目の粒度は、結構適当です。
フロントエンド系
フレームワーク
・Vue
Webアプリ開発で利用したフレームワークです。
選定理由は詳しく聞いていないですが、既にいくつかの案件で利用されていたようなので、
コンポーネント部品の再利用の観点で採用されているのかと思われます。
・Nuxt
Vue同様、Webアプリ開発で利用したフレームワークです。
内包しているのはVueのモジュールなので、基本的にVueと大差はないです。
通常のVueフレームワークよりSPAやSSR(サーバサイドレンダリング)などの
機能・運用的メリットで使ったりしていました。
単項目チェック
・Vuelidate
細かい機能の話ですが、画面を作っていく際に
どうしても入力フォームに対して、必須項目設定や半角英数字制限などを書けないといけない要件が出てきます。
Vue系統のフレームワークを使っていれば、Vuelidateが使えます。
導入や設定も楽ですし、各入力フォームに対して、
かなりリッチに単項目のチェック機能が実装できるので、使っていて楽でした。
画面制御
・Navigation Guards
こちらもVue系統のフレームワーク限定ですが、画面制御はGuard機能を使いました。
手続き完了後に前の画面に戻れないようにする処理を簡単に実装できたので、使い勝手は良いです。
利用する際には、各ページコンポーネントの名前が必要になってくるため、
ちゃんとページ毎にname設定をしておきましょう。
画面デザイン
・Atomic Design
Atomic Design とは、コンポーネント単位で設計していくデザイン・開発手法です。
詳しい内容は、以下の記事が分かりやすいです。
基本は、以下の5つの構成要素で部品を作成・管理するようですが、
私が関わったところは、全てtemplatesを削除していました。
理由としては、「管理コストの削減」と「役割の集約化」がメインだと思います。
templatesとpagesは役割として似ているところもあるので、統一したことで混乱は避けられたのかなと思います。
(実際に使った上で検討はしてみたいですが、やる勇気はないです)
・Grid Design
主にスマホのレスポンシブ対応を解決させるために導入しました、
グリッドデザインで画面を作ることで、画面幅によって
表示領域を端末に合わせて変えることができます。
LINE アプリ開発
・LIFF
LIFFはLINE Front-end Frameworkの略で、Webアプリに取り込むことで
LINEアプリにプッシュ通知を行ったり、ユーザIDでアクセス制御ができます。
導入には、LINE Developersコンソールに入れるアカウントや
アカウントで発行できるアクセストークンなどが必要になってきます。
引用元: Messaging APIの仕組み
その他ノウハウ
・Auth0
ユーザ認証基盤として導入しましたが、
詳しい内容については、あまり深く入り切れていないです。
ただ、AWS Cognitoと比較するとCognitoの方が良かったのでは
という話も出てきたりしています。
Auth0がデフォルトで表示してくれるログインフォームなどの細かい部品について、
デザインの変更が難しいとのことを聞いています。
他にもいろいろあったと思いますが、別途知っている人に聞きに行こうかと思います。
引用元: 次世代認証基盤サービス「Auth0」
・New Relic
こちらもAuth0同様に
主担当で入れていなかったので、深く書けませんが、
AWS上のログ監視を本格導入するにあたってNew Relicを導入しています。
まだどれくらい役に立つか実感はないですが、
導入についていうと、結構根気が必要というのはわかりました。
導入の横展開をするにしても、しっかりドキュメント化しておかないとダメそうです。
引用元: Why New Relic?
https://www.google.com/search?q=New+Relic&oq=New+Relic&aqs=chrome..69i57&sourceid=chrome&ie=UTF-8www.google.com
・Google Analytics(GA)
言わずと知れたユーザアクセス分析ツールです。
各画面でのユーザ離脱率や任意のボタンをクリックしているかなどを
集約して見える化してくれます。
Vue.jsやNuxtのイベント発火処理内に、GA用のイベント送信メソッドを呼び出すことで
任意の箇所でユーザ操作が行われているかの検知処理が実装できます。
・パズル認証(CAPY)
個人的に面白かった外部サービスのパズル認証です。
こちらはボット攻撃を防ぎつつ、不正なアクセスログがあれば検知する
セキュリティ向上を目的として導入しています。
導入については、CAPY用のコンソールからパズル認証用のURLを発行したうえで
Webアプリ側から呼び出すとできます。
パズルの難易度やデザインをコンソール側で簡単に変えられるので、
中々面白い外部サービスでした。
引用元: Capy Puzzle CAPTCHA
・住所検索(Mapion)
住所検索用の外部サービスです。
導入はかなり簡単で、指定のアドレスに対して郵便番号を渡すと住所情報が返ってきます。
ただ、住所が見つからなかったときは、空で返却されたり
一つの郵便番号で複数の住所情報が返却されたりと
実装上考慮する点は多々あるので、注意が必要といった印象です。
・決済サービス(Paygent)
株式会社ペイジェントが提供するマルチペイメント決済サービスです。
下記の画像のようにトークンを使ってカードの認証を行い決済を行います。
引用元: ペイジェント、決済代行サービスで「トークン決済」を提供
マニュアルや問い合わせについては全て日本語なので、先に登場するStripeよりかは入りやすいのかと思います。
・決済サービス(Stripe)
海外の企業が提供するPaygent同様のマルチペイメント決済サービスです。
マニュアルはweb上で公開されているものを中心に実装できます。ちなみに中身は全て英語です。
導入はPaygentよりは簡単で、Stripe専用のWebコンソールで決済内容や取引内容を管理できるので、コスト面が低いです。
また、かなりの事例を持っているサービスなので、セキュリティも高いと思います。
・TypeScript
いきなりプログラミング言語の話ですが、プロジェクトを通して、使っていて良かったと言う場面が多々ありました。
例えば、APIの仕様変更によってリクエストパラメータが一律変更があった場合でも、型が変わるので、すぐに影響箇所を確認できます。
ただ、使い方やルールを決めておかないと型管理が複雑になってくるので、規約作りは最初にちゃんとしておいた方がいいです。
TypeScriptを使える機会があれば、絶対に使った方がいいと思いました。
・CSRF対応(トークン制御)
セキュリティ対応で取り入れた処理です。
サーバ側で作成したJWTトークンを使って、申し込み手続きを行ってもらうことで、不正な申し込みをさせないようにします。
認証基盤としてはAWSのAuthorizerを使います。
・逆SEO対策(no-index)
よくある対応なのかもしれませんが、公開情報として一般的な検索でヒットしないwebページを作る必要が要件によっては出てきます。
対応としては、HTMLのmeta情報にno-indexの指定を入れるだけですが、結構忘れがちなので覚えておいた方がいいことの一つです。
バックエンド系&基盤系
主開発系
・API Gateway
各種APIの処理を束ねて管理できるAWSのサービスです。
基本的に複数のLambda関数のAPI処理を束ねるために使っていました。
また、AWS認証機能であるAuthorizerの管理・付与などもここでできます。
セキュリティ観点やAPIモニタリングの観点でも必須のサービスだと思います。
引用元: API Gateway の仕組み
・Lambda
サーバレスでプログラム処理を作れるAWSサービスです。
プロジェクトでは、DBとの通信処理や外部サービスとの通信処理をLambdaで行っていました。
Lambdaに対してCloudWatch(ログ監視サービス)の設定ができるので、情報ログやエラーログをLambda内に定義しておけば、
毎回のAPI通信のたびにログを出力できます。
注意点として、関数実行時に最長 15 分以上の時間が掛かると
自動的にタイムアウトしてしまう仕様になっているので、
かなり複雑な処理で時間が掛かる場合は避けた方がいいです。
(それか、性能を改善するか)
引用元: AWS Lambda
・S3
S3は、一言で言うとAWSのクラウドストレージサービスです。
自由にファイルストレージとして使えますし、
静的Webホスティング機能も持っているので、
HTMLやVue.js・Nuxtで作成したSPA資産をホスティングできます。
・Dynamo DB
Dynamo DBは、AWSが提供するNoSQLデータベースです。
一般的なRDSとは違って扱いは簡単で、
AWSコンソールから簡単に作成できますし、
Lambda関数からのCRUD処理も難なくできます。
また、テーブルデータに対して有効期限(TTL)の設定を付与できるので、
一定時間後に自動削除も簡単に設定できます。
ただTTLに関しては最大48時間削除に時間を有する可能性があると公式に書いているので、
正確な時刻に削除してくれるわけではないので注意です。
公式：仕組み: DynamoDB の有効期限 (TTL) - Amazon DynamoDB
参考文献：TTL を有効化した DynamoDB でちょっと焦った話 - サーバーワークスエンジニアブログ
・Cloud Front
Cloud Frontは、Webサイトコンテンツを公開・配信するのに適した環境を提供してくれるサービスです。
サービス自体のセキュリティ・耐久性が高く、よっぽどのことがない限り
Cloud Front自体が止まることはないです。
また、コンテンツ配信については、分散型で管理するので
海外であっても一定の通信速度で配信できる仕組みを持っているそうです。
プロジェクトでは、Webサイトの入り口としてCloud Frontを用意して
代替ドメイン名 (CNAME) の設定などを行いドメイン名の固定化を行っていました。
Cloud Frontでもログ監視ができるので、アクセス証跡も残すことができます。
開発支援系
・Code Commit
Code Commitは、一般的なコードバージョン管理サービスです。
Gitで管理したうえで、Code Build・Code Pipelineの組み合わせて
CI/CDを実現させています。
管理上、1ユーザが扱えるリポジトリは制限をされていたため、
gitの複製には専用のGit 認証情報を発行していました。
CodeCommit での IAM の使用: Git 認証情報、SSH キー、および AWS アクセスキー - AWS Identity and Access Management
・Code Build
Code Buildは、CI/CDを行う上で必要なビルドサーバの設定や
起動ログなどのモニタリングの機能を提供しています。
資源のデプロイ中にエラーになった場合、ここのビルドサーバを確認します。
また、ビルドの詳細やCode Pipelineで管理する処理フローを記述する
buildspecファイルは、Code Buildが解読して処理しています。
・Code Pipeline
Code Pipelineは、CI/CD周りの処理フローを管理しているサービスです。
CI/CDの発火開始イベントを設定し、
実行時にはbuildspecファイルに書かれている処理フローを可視化してくれます。
基本的にCI/CDの発火開始イベントは、Code Commitで管理しているGitリポジトリの
各ブランチ資産がリモート反映されたタイミングになると思います。
・Cloud Watch
Cloud Watchは、ログやアクセス状況などのモニタリングサービスです。
プロジェクトでは、API Gatewayや各Lambda関数のロググループを作成し、
ログ監視を行っていました。
引用元: Amazon CloudWatch
・Systems Manager
Systems Managerは、AWS内の運用管理上必要な機能が提供されています。
主に利用した機能は、ストアパラメータ機能です。
セキュリティ上、アプリやサーバ側に保持しておきたくないデータを
ストア情報としてストアパラメータに登録することで、
安全にアプリ側から取得できるようになります。
・Cloud Formation
Cloud Formationは、AWSリソースのCI/CDを可能にしてくれるサービスです。
プロジェクトでは、API Gateway・AWS Lambda・DynamoDBを
Code PipelineとCloudFormationを組み合わせて自動デプロイしていました。
設定自体も簡単で、Cloud Formationに設定情報を読み込ませるための
設定ファイルを作成するだけで構築できます。
そのほかのAWSサービスでもAWSリソースのデプロイに関係する場合は、
Cloud Formationが使われていたりもします。
参考： 最近のAWSはyamlを書かずにデプロイできるらしい - SHOW Toro TIME
その他ノウハウ
・署名付きURL発行
ちょっとニッチな機能かもですが、
S3に置かれているファイルをWebアプリから参照する場合、
AWSのセキュリティ的に安全な経路でしかアクセスできないようにするためのURLを
個別で発行できます。
また、URLについては有効期限も設定できるので、一定時間後に参照できなくさせることも可能です。
導入には、Cloud FrontやS3が必要になってきます。
・S3 レプリケート(コピー)
S3にはアップロードされたファイルを自動検知して、別のS3バケットにコピーする機能があります。
S3レプリケートに関しては、タイムラグが15分ほど時間が掛かる場合があるので、
瞬時にコピーされるような作りではないです。
・認証制御(Authorizer)
Authorizerは、API Gatewayで管理する認証制御機能です。
それぞれのLambda関数を呼び出す際に、Authorizerを呼び出し
必要な認証上のチェック処理を間に挟むことができます。
プロジェクトでは、ヘッダーに適切なJWTトークンがないと処理を実行しないような作りとして
Authorizerを使用していました。
導入については、それほど難しくはなく
AWSコンソール上でもできますし、Cloud Formationから自動的に
デプロイすることも可能です。
開発基盤系&コミュニケーション基盤系
Amazon Workspaces
Amazon Workspacesは、クラウドでWindowsやLinuxを利用できる環境を各ユーザごとに提供してくれます。 プロジェクトでは、30名ほど共通のクラウド開発端末として環境を用意し、特定の環境下で作業するために使っていました。 実際に以下の環境を作ることができます。
リモートワークが展開される昨今の状況にはとてもマッチしたサービスかと思います。 セキュリティ観点としても、一元的に管理・展開できる点がプロジェクトで利用するとしたら便利ですね。
Zoom
プロジェクトでは常に誰かと会話しながら進める必要があるので、 リモート会議ツールとしてZoomを活用していました。
特にブレイクアウトルームという会話できる場所を複数作成する機能をうまく活用していて、 各チームごとに分かれて会話できる環境を作っていました。 このルームを作っておくことで、そのルームにいるメンバーに対して 聞きたいことがあればいつでも乗り込んで質問をしに行けるようになったので、 これだけで、チーム間のコミュニケーションコストをかなり軽くできたのかなと思っています。
Miro
Miroは、みんなで同時編集できるオンラインボードです。 かなり自由度が高く、基本的には付箋を使ったワークなどにMiroを使いますが、他にも簡単なグラフの作成や図形での作図ができます。
バックアップは自動で取られているようで、公式サーバ側のトラブルで Miroボードのデータが壊れた場合は復旧してくれます。 ただ、指定の時間まで復旧するといったリッチなバックアップはないので、 各自でバックアップ体制を考えておく必要があります。 (定期的に別ボードにコピーしておくなど)
Slack
Slackはプロジェクト内のチャットツールとして使っていました。 ここもZoomのブレイクアウトルームのように、チームごとにチャンネルを作成して 共有したい情報の切り分けと集約を行っていました。 緊急の連絡やちょっとした質問はすべてSlackを使って、確認を取っていました。 ただ、機密情報の共有やプロジェクト関係のファイル共有のやり取りは、 セキュリティ的にアウトなので、その辺りは注意してSlackを活用していました。
どのプロジェクトでもチャットツールは絶対に欲しいツールですよね！
最後に
ちょっとたくさん書き過ぎました。
概要ぐらいしかかけていないので、
詳しい話はまた別の場でアウトプットしようかと思います。
以上です。
