AWS JAPAN APN ブログ
パートナーに聞く!FTR 通過を目指すべき理由とは?【前編】
2021年から、ソフトウェアソリューションをお持ちの AWS パートナーは AWS ISV パートナーパス に参加いただけるようになりました。旧 テクノロジパートナーだった ISV パートナーはもちろん、コンサルティングパートナーも活用いただける ISV パートナーパス。では、AWS ISV パートナーパスで AWS ファンデーショナルテクニカルレビュー (FTR) を通過すると何が良いのでしょうか?
今回は要件でもありながら、それ自体にメリットがある FTR について、パートナー事例から考えていきたいと思います。株式会社Serverless Operations は、2020年7月にセレクトティアを達成され、2021年5月に AWS コンサルティングパートナーとして初めて FTR を通過されました。ISV・コンサルティングパートナーの垣根を超えたお話を伺いたいと、この度 AWS パートナーソリューションアーキテクト (PSA) の櫻谷が、同社取締役COO の金仙優氏にインタビューしてきました。これから ISV パートナーパスを活用したいパートナー必読の内容です!
AWS 櫻谷 (以下略): FTR 通過おめでとうございます。元々高い技術力をお持ちとはいえ、FTR を1か月強の対応で通過される例は珍しく、素晴らしいモデルケースでした。まずは対象のソリューションについて教えてください。
Serverless Operations 金氏 (以下略): 今回 FTR を通過したのは「Costless」という、 AWS のサーバレスアーキテクチャにフォーカスしたコストの監視・可視化サービスです。サーバレスは、従量課金制で最初は始めやすいのですが、サービスが成長していくにつれコストの計算や構造が分かりづらくなるケースがあります。例えば、何年後にどれくらいコストがかかっているか、ユーザートレンドやシステム構成によっても変わってきますので、開発時には予算が立てづらいことがあります。そこをペインポイントと捉える企業が多いので、解決できるサービスがあるといいなと思って作ったソリューションが、Costless です。利用状況が分かりやすく見えたり、集計が簡単に出せたり、データを持ち出す必要がない点も、お客様に評価いただいています。
現在は AWS Marketplace で出品しており、AWS Lambda、Amazon DynamoDB, Amazon API Gateway, AWS Step Functions に対応しています。
AWS Marketplace での出品は、最初から検討されていたのですか?
最初は別の決済の仕組みを考えていましたが、AWS を使っているユーザーをターゲットとしているので、AWS Marketplace のほうがいいかなと途中で切り替えました。AWS の利用料金に含まれて請求されるほうが、AWS ユーザーにとって使いやすいですし、グローバルで使ってもらえるということもメリットだと考えました。
なるほど。ところで、FTR についてはどのように情報収集や準備をされましたか?
今年初めに ISV パートナーパスと FTR のことを聞き、すぐ準備を始めました。FTR ウェブサイトから入手できるチェックリストを見つつ、データのバックアップや障害時の対応などについては、AWS の公式ドキュメントや AWS Black Belt Online Seminar シリーズ を参照しました。よく「AWS の課題にふちあたったら、まず AWS のベストプラクティスを探せ」と言われたりしますが、AWS の観点を理解するためにも、AWS の公式情報を見るようにしていました。AWS Well-Architected で気になった項目をメモして解決策を調べたり、 FTR のウェビナー録画 や関連資料も見たりもしました。「考え漏れ」に気づけたという点では、AWS Well-Architected や FTR Lens の設問が役に立ったと思います。
ISV パートナーパスや FTR の概要で、分かりづらい部分はありましたか?
最初は「なぜ ISV パートナーパスという仕組みに変わるのかな」と疑問に思っていたのですが、FTR 対策をしながら AWS の意図が理解できました。コンサルティングパートナー・テクノロジパートナーという分け方よりは、ソリューションベースでの検証になったほうが、技術的な観点でも定期的にしっかりチェックされますよね。パートナーも気を抜かずに対応していかないといけないと感じました。
FTR のレビューはいかがでしたか?難しかったところはありますか?
「考え漏れ」というのでしょうか、頭の中には入っていたけれど言語化できていない部分を、対面監査で説明して納得してもらえるようにしていくプロセスが大変でした。今まで経験してきた案件や社内ワークで考えてきたこと以上に、細かく厳しい問いがあったので、詳細まで詰めて考えていかないといけなかったですね。例えばアプリの運用で「マネージドサービス使っていますよ」で乗り切ってきた部分なども、DR (ディザスタリカバリ) や四半期ごとの監査について細かなチェックが入ります。その辺りを、ちゃんと体系的に開発プロセスとして意識するようになったのは、チャレンジングでしたが、結果としてとても良かったと思いました。詳細を明文化して、定期的にチェックすることを忘れないための仕組みまで考えることができました。
技術的にはいかがでしたか?レビュー項目については納得感がありましたか?
サービス自体がそこまで複雑なものではないので、技術的にすごく大変ということはありませんでした。ただ、DR (ディザスタリカバリ) など、サービスを継続するためには考えないといけない部分が、社内で一番じっくり考えたところですね。レビュー項目については、ルートアカウントは使わないなど当然の項目もありましたが、基本確認の意図で入っているのですよね。Well-Architected は総合的には良かったのですが、曖昧で回答が難しい項目もありました。
これから FTR に挑戦されるパートナーへのアドバイスはありますか?
自社サービスは「みんな知っているよね」と言語化を忘れがちだったりすることもあると思いますが、ドキュメントで残し、詳細まで客観的に説明できるようにすることをお勧めします。そのためには、普段からドキュメント化を意識する必要があります。「ここは大丈夫」と思っていた部分も、優先順位が低くなっていないか、考え漏れがないか、詰めて考えることが大事だと思います。
御社ではサーバレスを中心にマネージドサービスを多く活用されています。この辺りはレビュー通過にどのように寄与しましたか?今回のレビューでは、対応が必要と判断された項目が比較的少なめでしたね。
弊社のミッションが「サーバーレスでの開発を通しクラウドの価値そのものを最大限引き出し、顧客のビジネスを大きく加速させること」なので、 100% サーバレスを目指したいですね。レビューに関しては、手動で Amazon EC2 を管理するようなケースと比べると、サーバーレスはその部分を AWS にオフロードしてビジネスに集中できるのでおすすめです。普段から AWS のマネージドサービスをうまく積極的に使うことで、レビューの対応負荷も減らせると思いました。
後半は「FTR 対応の優先度をどう考える?」「ISV パートナーパスの価値をどう捉える?」など、さらに深い話をお届けしていきます!
ISV パートナーパスと FTR の概要を理解するには >> APN ナビゲート – AWS ISV パートナーパス
FTR の進め方をさらに詳しく理解するには (エンジニア向け) >> AWS PartnerCast ウェビナー録画