Zenn
chot Inc. tech blogPublicationへの投稿
🐟

FTPサーバを立てる物語

itoudium
2023/12/08に公開
AWS
Linux
EC2
#
アーキテクチャ
#
ftp
tech


https://adventar.org/calendars/8910

この記事は、ちょっと株式会社 Advent Calendar 2023 の8日目の記事です。

私はいま、ちょっと株式会社の技術基盤部で働いています。この部署は、色々な課題を取り扱っていて、名前の通り開発基盤を整える役割、新規事業の立ち上げ、また、チョット難しそうなプロジェクトを手助けする遊軍でもあります。

導入〜はじめに〜

この記事では、Jamstackへのリニューアルプロジェクト中に直面した、FTPシステムの課題と、私達のアプローチについて共有します。私は普段バックエンドで、サーバーレスや、コンテナアプリケーションを構築することが多いので、あまり無い経験をしました。
イケてるライブラリもモダンなテクニックも登場しません。ちょっとしたエッセイだと思ってもらえれば。

今回扱うのは、Webサイト・CMSのリニューアル案件で、WebサイトのほうはJamstackとなっています。
その既存システムの一部に、デジタルカメラから写真をFTPで直接入稿し、リアルタイムにサイトに掲載するというシステムがありました。
Jamstackリニューアルに伴い、この一連のFTPシステムをどうにかする必要がありました。
なお、記事の内容は、Jamstackほとんど関係ありません。

プロジェクトが向かう方向

FTPといえば、古くから存在するファイル転送のためのプロトコルです。私は、中学生のころには黒い画面のCLIでFTPコマンドを対話式でパチパチと打ったり、自宅サーバでFTPサーバを立てたりしていた記憶があります。デュフフ。さておき、昔も今も、Webサイト制作で使ったことがある人は多いと思います。
FTPプロトコルは、暗号化されていないため、今の時代あえて選ぶのは不適切だという認識は持っていました。そこで、暗号化のためのオプションがいくつか存在します。

プロトコル 説明 セキュリティ特徴
FTP (File Transfer Protocol) 基本的なFTPプロトコル。データはユーザ名やパスワードも含めて平文で伝送される。 平文でのデータ伝送
SFTP (SSH FTP) SSHをベースにしたファイル転送プロトコル。SSHの仕組みで保護される。 SSHによるデータ保護、SSHサーバが必要
FTPS (FTP Secure) FTPをベースにTLSによるセキュリティを追加したプロトコル。 TLSによるデータ保護、TLS証明書が必要

このように、あえて理由があってFTPサーバを立てるならば、プロトコルも慎重に選んでいく必要があります。しかし、今回のプロジェクトでは、他にも留意すべき点がいくつかあります。

このFTPサーバにファイルを送信する「送信元」となるクライアントについて掘り下げます。今回のクライアントは、一般的なパソコンではなく、デジタルカメラのFTP機能となります。デジタルカメラは、LinuxなどのオープンソースなOSではなく、ITRON系のリアルタイムOSや、あるいはメーカーの独自OSであることが予想されます。こういったシステムでは、内部に実装されているプロトコルスタック・通信ドライバも、それ独自のものとなります。また、当該プロジェクトでは、カメラを特定できません。このメーカーのこの機種、といった具合に、デバイスを特定できれば楽ができたでしょう。これはリスクです。（結局、このプロジェクトの最後まで、実機を調達することはできませんでした）

リプレイス元となる「既存システム」についても気になる話があります。既存システムについてお客様にヒヤリングをしたところ、これまで色々なレンタルサーバやVPSを試してきたが、なぜかカメラから接続できなかったり、接続が安定しないなど、不満があったようです。色々試した結果、当時の「既存システム」で使っているサーバに落ち着いたということです。このように、謎の相性問題が発生するかもしれないので、これもリスクです。

プロジェクトが進むべき道は、いくつかありますが、私はどんなときも「松」「竹」「梅」を大事にしています。なにごとも、この3つからはじまります。
分析と説明を行い、利害関係者と調整して、どの道をゆくのかをマネージしていきます。

  • A: 既存FTPサーバや、画像取り込みシステムを、すべてそのまま流用する
    • お客様に、新サイト用のAPIだけ新たに生やしていただく
    • 既存業務に与える影響が最も少ない
  • B: 既存FTPサーバを流用。取り込みシステムだけ新規に構築する
    • 既存FTPサーバにポーリングで問い合わせをして、新サイトに反映させる仕組み
    • 安定運用実績がある既存サーバ。プロトコルの面で安心。
  • C: すべてリプレイス
    • よりリアルタイムな写真反映
    • セキュリティや保守性での利点を目指す

ここに上げていない分析や提案も多数ありますが、いろいろ調整した結果、パターンC（梅）でいこうということになりました。

当時作っていた「パターンC」構成図は、およそ下記のような感じです。

リスク対策と設計への反映

進む道は決まってきましたが、厄介な問題も残っています。
デバイスとFTPサーバとの間で相性問題のような事象が発生することについて、考えました。
これはおそらく、上のほうで述べた、FTPのプロトコルが関係しているものと考えました。素のFTPプロトコルは、暗号化によるプロテクトが無いため、推奨されません。そこで、いくつかのFTPサービス・プロバイダでは、SFTPやFTPSを強制しています。デバイス側がこれらのセキュアプロトコルに対応していない場合に、接続できない事態に至るものと考えられます。実際に、既存サーバは、素のFTPで運用されていることがわかりました。
というわけで、当プロジェクトでは、FTPプロトコルを受け入れることにし、そのリスクの緩和策を設計に盛り込んでいかなければいけません。FTPプロトコルで通信する部分は、かなり権限をしぼり、その他のシステムから可能な限り隔離するポリシーで設計を進めていきます。
既存システムにおける「FTPが不安定になる」という事象は、いまいち、わかりません。（後に推測確度を高めることができた）
こういった諸々の心配事があるため、プロジェクト進行上のリスクとして位置づけて、早期にプロトタイプ構築・いろいろな（現在運用している）デバイス実機での検証をすることで、リスクヘッジとします。

FTPサーバ選択の旅

FTPを少しいじって改めて実感したのが、送信は簡単だが、受信はなかなか大変ということです。
まず、AWSには、AWS Transfer Family というプロダクトがあり、マネージドなFTPプロトコルサーバを提供してくれます。これらを使うと、EFS や S3 といったストレージにファイルを格納することができます。しかし、ランニングコストが見合わないため、見送りました。
そこで、他のインフラを検討していくことになります。

インフラ

前提として、当システムは、なるべくAWS上に構築したいというニーズがありました。また、保守のコストを最小限に抑えるため、他のパートはすべてサーバーレスで構築していました。可能な限りサーバーレス、IaC、イミュータブルといったポリシーで構築したいという思惑もありました。
マネージドサービスが候補から外れるとなると、まず、コンテナ型のFTPサーバを検討しはじめました。

このアプローチでは、ファイルを受けるFTPサーバは、単なる窓口として、受け取ったファイルは即座に S3 に同期し、ファイルシステムには残しません。サーバのメンテナンスが必要になったら、コンテナを再デプロイします。ファイルシステムに重要はものは何もありません。セキュリティや保守性のうえでの利点を獲得することを目指します。

この時点では、最もシンプルにやることを考え、AWS AppRunner へのデプロイを最有力候補としていました。
AppRunner は AWS が提供するマネージドサービスで、簡単にコンテナアプリケーションをデプロイすることができます。

アプリケーションの選定

FTPサーバのアプリケーションも選定しなくてはいけません。
FTP受信の難しさの一つが、アプリケーションです。長く使われているソフトウェアなので、昔ながらの設定ファイルによる設定が必要ですし、Linuxのセキュリティシステムにも関わってきます。これらを、なるべく、シンプルにセキュアに解決する必要がありました。
昔から広く使われているメジャーなアプリケーションには、以下のようなものがあります。

  • vsftpd
  • ProFTPD
  • Pure-FTPd

認証システムにまつわる課題

FTPのためのユーザー認証をどうするのかも、考えなくてはいけません。
当システムでは、FTP利用者ごとに、別々のアカウントを発行する必要があります。当然、1度発行したら終わりというわけではなく、メンテナンスしていくことを考えなければいけません。
また、FTPアカウントの露出についても考えなくてはいけません。今回は、平文のFTPを開放することを前提にしています。多くのFTPサーバでは、LinuxユーザのID・パスワードでFTPにもログインすることが可能ですが、それをすると、Linuxユーザが割れてしまいます。
というわけで、いわゆる「仮想ユーザーアカウント」機能をサポートしているアプリケーションを選定しなくてはいけません。
また、この仮想ユーザアカウントを、いい感じにシンプルにメンテナンスできる仕組みも考えなくてはいけません。

vsftpd を試し、周辺環境を整えていく

認証

仮想ユーザアカウントを作ることができて、なるべくメジャーで使いやすそうなことから、vsftpd を使ってみることにしました。
vsftpd の仮想ユーザは、Linux の PAM（Pluggable Authentication Modules)を使って認証します。
PAMは、Linuxシステムの認証システムをモジューラ方式で管理するための仕組みです。標準の状態では、LinuxのPAMは、 /etc/passwd を使った認証を使いますが、PAMを使うと、全く違った認証メカニズムをシステムに登録することができます。今回の場合、認証メカニズムは PAM を使うため、いったん vsftpd から切り離されます。やることは、PAMの設定と、vsftpd でPAMを使うという設定です。

vsftpd の 認証まわりの設定は、ざっくり次のようになります。

vsftpd.conf
# for virtual users
chroot_local_user=YES
guest_enable=YES
guest_username=some-real-user-name
virtual_use_local_privs=YES
pam_service_name=vsftpd
local_root=/var/some-local-data-directory/
allow_writeable_chroot=YES

次に、PAMの設定をします。

/etc/pam.d/vsftpd
#%PAM-1.0
auth    required pam_userdb.so db=/etc/vsftpd
account required pam_userdb.so db=/etc/vsftpd

上記の pam_userdb.so というのがユーザー認証モジュールの名前です。この.soモジュールがシステムにインストールされている必要があります。 pam_userdb.so では、Berkeley DB という組み込みデータベースのデータファイルに記録されたユーザー認証情報を使います。
このDBファイルは、バイナリファイルで、専用のコマンド db_load で作成する必要があります。

DBファイルを作るための元データは、決まった書式で作る必要があります。

user.txt
ユーザー名1
パスワード1
ユーザー名2
パスワード2
（以下つづく）

このファイルを、以下のようにして、Berkely DB に変換します。その後、プレーンテキストの user.txt は削除します。

setup.sh
db_load -T -t hash -f user.txt /etc/vsftpd.db

全体を俯瞰して、以下のようなイメージで運用するシステムとしました。

このシステムでは、AWS Secrets Manager でテキスト形式でFTPアカウントを管理します。
そして、セットアップスクリプトのなかで、Secrets Manager からアカウント情報を取得し、PAMで使えるように変換します。
Linuxにシェルログインしてアカウントを手作業で管理するような真似は絶対にしたくありませんでした。
この時点で、アカウント管理については、だいぶ明るくなってきました。しかし、どのようにして、セットアップスクリプトを起動するのかは、考えなくてはいけません。

ログおよびメトリクス

vsftpd では、いくつかの選べるログオプションが存在します。
システムをどのように監視していくのかを考えながら、ログオプションを選んでいきます。

vsftpd には、FTPプロトコル単位での細かいログを出力する log_ftp_protocol というオプションもあり、デバイスからの接続のデバッグに便利でした。

最終的に vsftpd のログの設定は、以下のような感じにしました。

vsftpd.conf
xferlog_enable=YES
xferlog_std_format=NO
vsftpd_log_file=/var/log/vsftpd.log

FTPプロトコルのトラブルについては、FTPのログをよく見ることが重要です。ほとんどの問題が解決します。

そして、監視のために cloudwatch-agent と awslogs を常駐させ、ログを収集し、メトリクスを集計する仕組みを構築していきます。

これにより、FTPサーバが生きているか・死んでいるかを監視することができるようになりました。CloudWatchで集中監視できます。
また、アップロード成功・失敗や、ログイン成功・失敗といった重要な指標も、メトリクス化できるようにしました。

続いて、 fail2ban という不正アクセス検知・ブロックのためのツールも検証していますが、割愛。

後段へのファイル転送の仕組みを構築する

これまでで、FTPでファイルを受け取ることはできました。次は、このファイルをどうやって後段に控える画像管理システムに送るかを考えていきます。

システムの1つの組み方として、このFTPサーバと同じマシンに同居する形で、データベース処理などの「登録処理」を乗せることも考えられます。しかし、このFTPサーバはなるべく身軽にしてサーバーレスに寄せたいという明確なビジョンがありました。FTPサーバに載せた機能は保守やデバッグがしにくいパートになってしまいます。また、セキュリティの問題もあります。上に書いた通り、FTPサーバをなるべく隔離し、権限をしぼり、攻撃被弾面積を減らす狙いです。やはり、受け取ったファイルは、即座に S3 に転送。S3のイベントをトリガーにして Lambda で以後の処理を行うことが良さそうです。

AWS S3 にファイルを送るには、以下のような方法が考えられます。

  • FUSE (Filesystem in Userspace)
    • FUSE は、ファイルシステムをユーザー空間で構築するための仕組み
    • s3fs などのFUSEなツールを使うことで、S3バケットを簡単にファイルシステムにマウントできる
  • lsyncd を使う
    • lsyncd はファイルシステムの変更を検知して何かアクションをするデーモン
    • FUSE に比べて設定が複雑

一般的には、FUSEを使った方法が紹介されることが多いと思います。FUSEは、透過的に同期してくれる点は大きなメリットなのですが、難点もあります。
透過的ということは、そのぶん、裏側に複雑なシステムが存在して、人間をサポートしてくれているということです。
まず、いつ・どんなコマンドがS3に送られるのか、コントロールが難しいです。場合によっては、パフォーマンス問題に悩まされることもあります。また、複雑なしくみのうえに構築されているので、監視が難しくなります。それに、今回はもともと「同期」がしたいわけではなく、単なる送信がしたかったので、少し使いにくいです。
そこで、今回の用途にあった lsyncd を使って送信することにします。

いったん俯瞰すると、下図のようになります。ほとんど受け取ったファイルを投げるだけです。

lsyncd は、通常、ファイルの同期によく使われるのですが、カスタムスクリプトを書くことで、ファイル変更をキャッチして、処理を走らせることができます。

今回は、次のような感じで設定ファイルを記述して、ファイルアップロード時に AWS S3 にファイルをコピー、その後、ローカル側は破棄するスクリプトを作りました。

lsyncd.conf
-- lsyncd.conf lua scripting
settings {
    logfile = "/var/log/lsyncd/lsyncd.log",
    statusFile = "/var/log/lsyncd/lsyncd.status",
    nodaemon = false,
    insist = true,
    maxProcesses = 30,
}

s3sync = {
    onModify = "/root/some-script-directory/transfer.sh ^source^pathname ^target^pathname"
}

sync {
    s3sync,
    source = "/var/some-ftp-data-directory/",
    target = "s3://BUCKET/"
}

onModify と書かれているところが、ファイル作成や変更といったイベントで起動するスクリプトです。この中身では、パラメータで受け取ったファイルを、 AWS CLI を使って S3 に送信。その後、ファイルシステムのファイルは削除しています。（既存システムもこんな感じの挙動で、受理されたファイルは他の場所にmoveしていたようです）
ステージング環境、本番環境などマルチステージにしたかったので、送り先のS3バケット名は、デプロイ時にsedで置換します。

忘れてはいけないのが、lsyncd の監視です。vsftpdと同じ要領で、awslogs や cloudwatch-agent で、プロセスとログを監視するようにしました。これで、送信がエラーになったり、デーモンが死んでいるときに、メトリクスで監視できるようになります。

サーバーレス処理（Lambdaによる画像登録）

S3に画像を置いたあとの処理は、サーバーレスのイベントドリブンで実現します。
ここには、アップロードされたディレクトリやファイル名を分析する処理や、画像管理システムに適切なパラメータと共に登録する処理、また外部システムへの通知など、ビジネス上の要求を乗せていきます。ここが最もメンテナンスすることが想定される箇所です。詳細は省きます。

インフラ(2)

アプリケーション層（vsftpd周辺）が出来上がってきたので、インフラも引き続き検討していきます。

まず、AppRunner を検証しましたが、検証しはじめてすぐに、ポートの問題に気づきました。

FTPプロトコルでは、コマンド用のポート(21)とデータ通信用のポートの2種類のポートを使います。
コマンドポートで、認証や、各種制御コマンドの送受信を行いますが、ファイルの中身のデータは、データポートでやりとりします。

FTPプロトコルには、アクティブモードとパッシブ（PASV）モードがあります。アクティブモードは、クライアント側がポートオープンしなくてはいけなくて、現代のインターネットではほとんど使えないと言って良いです。よって、使うのは、PASVモードになります。
FTPプロトコルのPASVモードでは、以下のような段取りで、通信が確立されます。

  • コマンドポートで通信確立
  • クライアントがPASVコマンドを送信
  • サーバがそれに応えてデータポートをオープン。クライアントに伝える
  • クライアントがデータポートに接続し、通信確立

サーバ（vsftpd)は、設定ファイルでデータポートの範囲（数）をあらかじめ定義しておき、その範囲で適当なポートを開く仕組みになっています。この仕組みが、AppRunnerでは使えません。
AppRunnerは、単一のポートだけで待ち受けるアプリケーションを想定しているもので、複数のポートを露出することができないのです😭

次に、AWS ECS(Elastic Container Service)を検討します。
ECSでは、AppRunnerよりも設定が複雑化しますが、逆にカスタマイズできる余地が増えます。
しかし、ECSでも同様に、ポートの問題に当たります。
AWS ECS は、AppRunnerと違い、複数のポートを開いておくことができます。しかし、ポートの数がトータル5個に制限されてしまいます。
実際に実験してみましたが、複数のクライアントからFTPサーバに同時接続するときに、空きポートが無いと、新規接続が失敗するばかりか、ほかの接続もかなり不安定になります。
ここで、プロジェクト当初にお客様から聞いていた「FTPが不安定なことがある」という事象を思い出します。不十分なポート数だったことで、輻輳が発生することによって、不安定になっていたのでは。もちろん他の原因も考えられますが・・・。
直感的には、「常識的に考えて、ポートが足りない場合は、空くまで待つのでは？」という気がしますが、そんなことはありません。実際に試してみた感覚として、十分な数のデータポートが必要ということがわかってきました。
また、ECSでは、ロードバランサーの問題もあります。
ロードバランサー配下に複数のFTPサーバを立てる場合、例えば、コマンドポートとデータポートで、別々のコンテナに通信が振り分けられてしまう可能性があります。このロードバランサーの振り分けをstickyにすることは不可能なようです。このような、複数ポートで通信するアプリケーションの水平展開は、かなり難しいってわけです。ロードバランサーを使う場合は、水平分散はできない・させないことになります。

最終的に、AWS EC2の小さいインスタンスで構築することにします😂

EC2をがんばる

AWS EC2（Amazon Web Services Elastic Compute Cloud）は、クラウド上での仮想サーバです。マネージド・サービスや、サーバーレスに比べると、システム管理や、モニタリングなど、多くのことを考えなくてはいけません。

ECSやAppRunnerのようなコンテナアプリケーションとは違い、EC2では、昔ながらのサーバ管理やアプリケーション管理が必要になりますが、そのコストを最小限にし、全部コードで管理できるようにしたいと考えました。

EC2サーバをコード化するには、いくつかの方法がありますが、更新しやすさによって、コードの記述場所を変えていきます。

今回、基本的なIaCツールには、Terraformを使っています。まずは、cloud-initを使って、基本的なパッケージのインストールなどを記述します。ここは、よほどのことがなければ変更しないハードな部分となります。
EC2を配置するためのVPCも、Terraformで構築します。

それから、より頻繁に更新するパートを作り込んでいきますが、これには AWS CodeDeploy を利用することにしました。
このサーバには、vsftpd,lsyncd,awslogs,cloudwatch-agent などの、いくつかのアプリケーションが登場しますが、これらの設定ファイルはすべて、VCSで管理します。そして、CodeDeployでEC2インスタンスに送信し、スクリプト(Bash)で展開します。

このために、 CodeDeployエージェントのインストールを cloud-init に仕込みました。

CodeDeployでは、AppSpecというファイルにデプロイ時の挙動を書いていくことになります。
本来であれば、 BeforeInstall AfterInstall ApplicationStart ApplicationStop と各イベントに処理を書いていくのですが、今回、全部の処理をひとつのBashスクリプトでがんばっているので、appspecもシンプルになります。

appspec.yml
version: 0.0
os: linux
files:
  - source: /
    destination: /root/settings/
hooks:
  ApplicationStart:
    - location: scripts/setup.sh
      timeout: 300
      runas: root

setup.sh のなかに、設定ファイルのリプレイスや、認証情報の展開、デーモンの再起動などを書いていきます。
これで、だいたい全部コード化できました。ログインせずに外からデプロイできます。
前章で触れた通り、データの中身はS3にあるので、いつでも壊せるサーバになりました。いいですね。

セキュリティ的な留意事項

このEC2 FTPサーバは、セキュリティ的に弱点になりえますので、できるだけ隔離した設計を心がけました。

  • ほかのサーバがいない、分離されたVPCに配置した
  • IAMで権限を最小限にしぼった
    • ログやメトリクス送信、S3への書き込みなど、最小限に
  • 乗せるパッケージは最小限にした
  • yum-cronによる自動セキュリティアップデートを設定
    • （インスタンスのメモリが少なすぎるとアップデートが失敗する）

冗長化と回復力

プロジェクトのニーズとしては、このシステムにそこまで強い可用性が求められているわけではありませんでした。しかし、可能な限り、人の手を介さずに回復することが求められていました。
上に書いた通り、今回のシステムでは、ロードバランサーで分散することによる冗長化はできません。
そこで、「アクティブ／スタンバイ構成」をとって、ダウンしたら即座にスタンバイに切り替わる構成を検討しました。

これをやるには、いくつかのプランが考えられます。それぞれを検討してみました。

シナリオ 特徴・考慮点
NLB (Network Load Balancer) 常に1台のみアクティブにする。NLBの費用が発生。調停が難しそう
DNSによる冗長化 構成がシンプルで費用が安いが、ダウンしているマシンのIPアドレスも引けてしまうのでNG
Route53を使った冗長化 Route53で操作可能なドメインがない。また、デバイス側のDNSリゾルバの挙動が読めないため不安
EIP(ElasticIP)付け替えによる冗長化（★今回採用） 1台に公開用IPアドレスを付与。ダウン時に付け替える。監視のための仕組みが必要

他にも、例えば、HAProxyなどで自前でロードバランサーを作るとかもあるかもしれません。
今回は、中でもいちばんシンプルに済みそうで、確実に動作して、ランニングコストも抑えられる方法を取ろうとして、EIP付け替えをやってみました。

監視用のLambdaスクリプトを定期実行するようにして、以下のような処理を走らせます。

  • describe-instances コマンドでEC2マシンのリストを取得（通常、アクティブとスタンバイの2台が取れる）
  • 「公開用IP」があたっているほうのマシンをヘルスチェック
  • ダウンしていたら、ほかのマシンに「公開用IP」を associate-address コマンドで付与

という感じのシンプルなスクリプトで、監視・調停システムを作りました。

動作テスト

私は普段、Macを使っています。GUIでFTPをテストしたいときは、 FileZilla をよく使っています。ダブルクリックで送受信がはじまるなど、ちょっと慣れない挙動もあるけど、必要な働きをしてくれます。
また、もう少し慎重な動作確認や、複数同時接続を試したいときは、CLIの出番です。
最も原始的なCLIクライアントが ftp です。しかし、より高機能で使いやすい lftp を使うのが良さそうです。 ftp には対話式インターフェースしか無いのですが、 lftp だとワンライナーも書けるし、その他細かいところで使いやすくなっています。
例えば、 lftp でファイルを送信するには、以下のように -c パラメータにコマンドを並べます。（もちろん対話式でも使えます）

lftp  -c 'open -u username,password 127.0.0.1 ; cd some-dir ; put 1.jpg ; ls'

これはいい！

当時こんな感じでコマンドを並列で走らせて体感的な速度や安定感を見ていました。

また、Mac には、OS全体の通信速度を遅くする「Network Link Conditioner」という機能が存在します。デバイスは、通信環境が悪い場所からアップロードしてくるので、それを想定し、Macの通信を遅くしてのテストもしました。

それから、余裕をもった実機デバイスでの動作確認をお客様と一緒にしていきました。やっぱり実機の特定の機種だけで起こるトラブルもありました。（それは lsync　が原因だったような気がするが）

結論

というわけで、サーバーレスで構築されたプロジェクトのなかに、まるでオアシスのように、サーバが出現することとなりました。
サーバをできるだけ隔離し、責務を減らす。
重要なビジネスロジックはサーバーレス側に寄せる。
こんなコンセプトで設計構築や関係者との調整をしてきて、苦労はあったけど、ほとんど順調に収めることができました。

正式稼働後してしばらく経過していますが、期待通りの動作をしており、このコンセプトにしてよかったと感じています。実際に、機能追加やバグ修正といったアップデートは、サーバーレス側が中心となっています。サーバの様子は、定期的にチェックしていますが、外から観察できる状態になっており、SSHでログインすることはありません。

もちろんここに書いていない事も多いし、銀の弾丸みたいなことはありません。似たようなプロジェクトがあっても、そのときまた最適なものを模索する気がします。

大きなプロジェクトのなかの、ほんの小さなセクションですが、いろいろな能力が必要になることを再確認しました。

  • セキュリティに対する基本的な態度＝セキュリティ層を形成したり、被弾面積を小さくする
  • 責務を分割すること
  • ポリシーやコンセプトを持つこと
  • プロトコルへの理解
  • 大胆に仮説を立ててトラブルシューティングすること
  • 各種のモニタリング、可用性や回復力
  • 関係者との調整

はじめはリスクに慄きましたが、やってみると、結構楽しかったです。勉強になりました。

宣伝

ちょっと株式会社では、Webフロントエンドに興味があるエンジニアだけでなく、それを支えることに興味があるエンジニアも募集しています。お待ちしております。

chot Inc. tech blog
chot Inc. tech blogPublication

ちょっと株式会社（chot-inc.com）のエンジニアブログです。 フロントエンドエンジニア募集中！ カジュアル面接申し込みはこちらから chot-inc.com/recruit/iuj62owig

Discussion