AWS Solutions Constructsでシステム作成は楽になるのか？
実装・設計・非機能設計から見る、 活用のメリット
渡邉洋平氏（以下、渡邉）：「AWS Solutions Constructsで楽してシステム作りたいよ〜！」という話をします。よろしくお願いします。最初に今日のアジェンダです。まずは「AWS Solutions Constructsって何？ を調べてみました」。商用でも、実践的な知見ではないことは予めご了承ください。次に「Solutions Constructs×CDK v2で×記述の抽象化・省力化をどこまで実現できるのか」。最後に、「これならプロダクトに組み込めそう」と感じてもらえたらゴールだと思っています。
認定試験の勉強をしたエンジニアがいるだけでは解決しない、AWS環境作成
渡邉：まず、「Solutions Constructsとは」。「ぶっちゃけAWSで環境を作るのって？」という話ですが、外部のブログや公式を見て調べれば、ある1つのAWSのサービスを起動することはできます。ただ、実際の場面で需要があるのは数個から数十個のサービスを連携するシステムです。例えば、座学でAWSを勉強し、AWS Well-Architectedも理解し、認定試験の勉強もしたエンジニアがいるだけでは解決しないなにかが、実際に触るとある。それはなにかという話です。
「AWS Solutions Constructs」とは
渡邉：次は、Solutions Constructsがあるという話です。AWSの公式の記述を引用すると、「2つ以上のCDKのリソースを組み合わせてロギングや暗号化などのベストプラクティスを実装する複数サービスのパターンを提供します」。抽象度が高い構成がスッと作れるのがL3 Constructsの魅力です。
Constructsの概要と留意点
渡邉：「そもそもConstructsとは何か」。今回のイベントでもみなさん話していますが、CDKでは、作成したい1つ以上のリソースをConstructsという単位で扱っています。L1はCloudFormationに準ずるローレベルな設定、一つ一つ設定したい場合に使うのがL1 Constructsです。L2 Constructsは、ある程度良いデフォルト値だったり、おまじないのコードがすでに内包されていたり、あるいは便利なロジックが入っていて各リソースの効率的な実装がなされていたり。L2 Constructsの事例が一番多いと思います。
注意しなければいけないのは、L3 Constructs≠Solutions Constructsという点です。L3自体はecs-patterns or aws-ecs-patternsもあるので、Solutions Constructsは複数リソースの中でもさらにベストプラクティスに準じたサービス群のアセットだと理解するのが良さそうです。
まずは「Solutions Constructs」を使ってみる
渡邉：2つ目は「Solutions Constructsでは何ができるのか」です。調べればいろいろなうんちくが出てきますが、まずは使ってみようということです。v1時代、Solutions Constructsが発表された時は25種類ほどでしたが、現在はどれぐらいでしょうか。スライドの右にあるクエリでConstruct Hubを調べてみました。
さっそく貼っていますが、（CDK Typeが）CDK、CDK Major Versionがv2、（Programming Languageが）TypeScript、PublisherがAWS。おあつらえ向きの、Solutions Constructsというキーワードがあるのでそれを調べます。2022年3月時点では、54個ほどありました。この中には安定的版と実験的版の2種類があります。あくまでも主観ですが、サーバーレス構成でよく出てくるパターンはLambda、SNSではSTABLEが安定しているパターンが多いと思います。反対に、VPC主体のALBはWAFやCognitoを使った構成はこれからというものが多かった印象です。今回はSTABLEのみで作ってみたいと思います。
（スライドを指して）「作りたい構成」です。各リソースのリソース名は省いてしまったので左の言葉で補いますが、API GatewayはAPIのサービス、Kinesis Data Streamsはストリームのサービス。ストリームのデータをどんどんファイル化しているFirehose。さらにファイル置き場としてS3 Bucket。左から右にどんどん流れるように置いていきます。
上と下にあるのがCloudWatch LogsとIAM Role。2つのバケツがアクセスログ用のBucketです。このような構成を作りたいと思います。
正味10行もいかずにコーディングが完成
渡邉：コーディング（1/3）です。今回はTypeScriptで作ってみますが、そこに導入するためのモジュールを並べたpackage.jsonです。右の図は今日時点のLatest。一昨日（※登壇当時）aws-cdk-libのバージョンが上がったので急いでやり直しました。
着目してほしい点として、v2はaws-cdk-libにまとまっているところがメリットです。v2でもSolutions Constructsの各コンポーネントごとに明示的に書く必要があることには注意が必要です。またCDKとSolutions ConstructsのLatestは少し違う点にも気をつけてください。
コーディング（2/3）。書いたものが右に並んでいますが、3行目でインポートしたApiGatewayToKinesisStreamsというモジュールから、new ApiGatewayToKinesisStreamsでAPI GatewayとKinesis Streamsを1つずつ作ります。13行目から15行目でnewしているだけです。デフォルト値で作っています。
この3行は、1行でも書けますがここで作っています。リソースを細かく設定したい場合はPropsでチューニングできますが、あまり細かくできない点がメリットであり、デメリットでもあります。API GatewayとKinesis Streamsとロググループの一部が設定変更できます。
上がAWSのマネコン（Management Console）でAPI GatewayにPOST Recordした内容、下がKinesisFirehose経由でS3に格納されたファイルをcatで開いている図です。API Gatewayからstreamのデータを加工してファイル化したことを確認できました。
AWS Solution Constructsで作成したリソースは”いい感じ”になっているか
渡邉：次は実用の話。システムは無事に作れたかという問題です。APIを叩くとS3にファイルがあります。では、商用に使えるのか。公式には「ベストプラクティスを実装」と書いてありますが、ユーザー的には実際に手を動かして書いていない部分の設定レベルを知りたいので、ビルド後の資材をテストしようというのが次のお話です。
テストで知りたいのは、「AWS サポートラインの定義 Solutions Constructsで作ったリソースが“いい感じ”になっているか」。「いい感じ」って曖昧ですね。明らかにダメな設定がないか。例えばEC2のセキュリティグループの穴が全開になっているとか、rootアカウントのアクセスキーがなにかあるとか。そういった明らかにダメな設定をまず潰したいです。もしあれば、抽象化しても使いたくないと思います。
テスト用ツールは大きく分けて2種類。1つはAWSのSecurity Hub Standardsで、AWSが選んでくれているConfigRuleの詰め合わせ。Standardsは、良くない設定値を指摘してくれるサービスの詰め合わせみたいなものです。大きく3種類あり、使っている方はご存じだと思いますが、一番メンテナンスが活発でアクティブなFSBP（AWS Foundational Security Best Practices standard）というルールセットを使いたいと思います。
ルールはたくさんありますが、その中でも今回関係ありそうなAPI Gateway、IAM、S3を見ていきます。OSSのLinterもいろいろありました。CloudFormation LinterはCDKが自動生成しているのであまり見なくてもいいと思いますが、一応書きました。ほかにはcfn-nagです。CloudFormation Guardという似たソリューションがあるのですが、デフォルトのルールが入っていないので、今回はこちらを選んで試作してみようと思います。CheckovはBridgeCrew社の静的解析ツールで、こちらもAWSのCloudFormationに対応しているので採用しました。ちなみにTerraformやコンテナ系にも対応しているようです。
Security HubとLinterのテスト結果
渡邉：Security Hubテストを試した結果、23個中19個くらいのルールはパスしていました。パスできなかったルールを簡単に列挙して見てみます。S3のアクセスログがEnable、LifesyclePolicyがEnableという点がちょっとコケていました。ただ、2つ作っておいたNGのバケットはアクセスログ用のみです。アクセスログのアクセスログを取ってもという設定意図は理解できますし、LifesyclePolicyもそのとおりだと思います。もし気になる場合は下の設定値で抑制するのも手だと思っています。
API Gatewayもバックエンド認証にSSL証明書を使っているか。これはセキュリティ要件次第で、デフォルトで満たしているかどうかはケースバイケースだと思っています。API GatewayにWAFが関連付けられているかどうかについては、今回のモジュール名から見てもわかるとおり、スコープ外なので納得といえば納得という感じです。
気になる方はAPI GatewayとWAFのSolutions Constructsがあるので採用するのもいいと思います。一応まだエクスペリメンタル状態なので、自己責任というステータスとのことです。
Linterですが、上の2つについてはぜんぜん引っかかりませんでした。後者についてはオチがあるので後ほど話します。Checkovは76件中70件通っていたのでいいのではないかと思いますが、通っていなかったところを見ると、CloudWatch Logsの暗号化やretention daysがうまくキャッシュしていませんでした。
テスト結果の振り返り
渡邉：テスト結果の振り返りです。コアなリソースの設定レベルは、わりとチェッカーをパスしたのではないかと思っています。あくまで一般的なチェックなので、あとでプロダクトに必要なテストはやるべきですが、ベースラインとしては悪くないと思っています。
Solutions Constructsを使えばシステム作成は楽になるのか
渡邉：まとめです。結局、Solutions Constructsで楽できるようになったのかについては、実装でかなり楽ができました。要件に応じたテストは必要ですが、リソース間の結びつきも含めて数行で説明できます。非機能設計も、CloudWatch LogsやIAM Logsも今回かなりうまくいきました。特にコードを書くことすらなく、ベストなものが作れました。結局細かく書きたくなってL2やL1をもう一度書き直すにしても、今回の設定を下地にすることで学ぶべき点は多いと思います。
CDKはL1、L2 Constructsだけでも充分利用できますが、CDKを使うのであれば選択肢の1つとして持っておきたいと、今回Solutions Constructsを使ってみてわかりました。みなさんもチャレンジしてくれるとうれしいです。ありがとうございました。
吉田真吾氏（以下、吉田）：ありがとうございました。ソリューションと言いつつ、プリミティブな感じに見えるものが多い気はします。業務系のエンジニアが「ソリューション」と聞くと、業務プロセスがこのセットアップでボンッみたいな、イベントデータを通したら出来上がり、みたいに勘違いしちゃうかもしれません。
少なくとも、ありがちなL2 Constructsで一つ一つのサービスを立ち上げて、つなぎ方だったり。例えばAPI GatewayとLambdaなら、ロールが適切にセットアップされているか、ソリューションで追加のConfigを入れれば使えるレベルで、設定のし忘れや実装のし忘れをなくすことができるのかなと思いました。単純に充実するといいですよね。
渡邉：そうですね。VPC系やALB系があればサーバーレスでヒットしない人でも使えると思うので、そこは期待しています。
吉田：そうですね。僕がサーバーレス以外でやる気が起きない原因は、途端に扱うリソースの数が増えて、どこか設定をし忘れると丸っきり動かなくなって、「やだ、もういい」みたいな（笑）。サーバーレスでやるからいいとなりがちなんですよ（笑）。そういうのも含めて入れるといいですよね。
吉田：新井田さん、質問が来ていればお願いします。
新井田晃史氏（以下、新井田）：質問が来ています。「L3 Constructsは、ALBとかVPCとかを意識しなくてよく、VPCとかも指定できるので既存VPCへのデプロイもできそうですが、カスタマイズにも制約があると思います。カスタマイズをしたいかどうかでL2、L3を使い分けるのでしょうか」。
渡邉：考え方としては、L2とL1の使い分けに近いのではと思っていて、まずL3、L2で始めてみる。L3がフィットするようであればそこから始めるという選択肢が今回新しく増えた。これが今回の発表の肝だと思っているので、そういう観点です。
吉田：同一のVPCで、ソリューションという言い方をしますが、1つのソリューションが既存のVPC上にすでに乗っていて、もう1つ別のソリューションが同一のVPCに同居しなければいけない場合に解決しなければいけない問題なんだろうと思ったんですが、なにかありますか？
渡邉：指定できるものとできないものがあって、existing〇〇で指定できるものについては既存のVPCのIDをCDKの何かで取ってきて、それを指定してあげるだけでいい。うまくくっつかなかったり、Propsがうまく合わなかったりした時に、初めてもう少しL2でレベルを下げて書いてみようという気になると思います。
吉田：なるほど。そういう課題が発生してもやれなくはないから、やる方向で問題ない。やる時に、L2でやるのかを検討する必要があるということですね。
渡邉：そうだと思っています。
吉田：藤井さんはいかがですか？
藤井貴昭氏（以下、藤井）：中身を覗いてみて、EKSを作るのが面倒くさいものも部品が揃っていそうなので、渡邉さんのように中身をチェックしてうまく使えるものを使っていくと、すごく楽になるんじゃないかと思いました。
Terraform v1.2の新機能preconditionとpostconditionを調べた
上記のように、まずvariablesからdata sourceでインスタンスタイプを取得して、そのインスタンスタイプのEBS最適化がサポートされているかをaws_instanceのpreconditionでチェックする、という事ができます。サポートされていない場合、 error_message で定義されたエラーメッセージが表示され処理がストップします。このように、従来のvariablesのバリデーションでは実現できなかった、動的に導出される値に対してバリデーションがかけられる、というのがこのprecondition、postconditionのポイントです。
preconditionとpostcondition、使い分けの指針
前述のEBS最適化がサポートされているか云々の例でいうと、以下のように インスタンスタイプのdata sourceのpostconditionとしてバリデーションをかけることもできますよね。
公式ドキュメントではチェックの目的がassumption(想定)なのかgurantee(保証)なのかで使い分けてくださいと述べられています。つまり、そのresourceを作成する、もしくはdata sourceを取得するための文字通り前提条件(=precondition)はpreconditionとして書く。そのresource・data サポートラインの定義 sourceが持つべき特性(他のresourceやdata sourceがこの特性を信頼できる(=前提とできる))はpostconditionとして書く、ということです。ちょっと抽象的ですが…
- どこでエラーメッセージがレポートされるのが一番わかりやすいか？ : precondition/postconditionのエラーはそれが定義されたオブジェクトのブロックにてレポートされます。開発者にとって一番わかりやすい場所がどこか考えましょう。
- 利便性: リソースAのあるattribute値がリソースB,C,D,Eの前提条件となっている場合、リソースB,C,D,Eでそれぞれpreconditionを書くより、リソースAのpostconditionひとつを書くほうが実用的です。
- 両方書く: これは依存関係を持つオブジェクト同士が別々のモジュールにいる場合に有効的です。それぞれのモジュールが独自に改良され続けていったとしても、お互いを検証し続けることができます。
apply時にしかチェックしない、事もある
あるresource(便宜上resource Aと名付けます)のprecondition/postcondition内で、別のresource(サポートラインの定義 resource Bと名付けます)のattributesを参照している場合、このprecondition/postconditionはresource Bを作成してからじゃないとチェックできないです。ですのでplan時にはこのチェックは行われず、apply時にのみチェックされる場合があります。「場合がある」というのは、resource Bがすでに作成されている状況においてはplan時にもチェックされるからです。要は「可能な限りできるだけ早くチェックする」と考えればOKです。
物流管理システムの比較14選。タイプ別の選び方
東証一部上場企業や大規模EC、欧米企業などの大規模かつ高難易度の導入実績も豊富なクラウド型の倉庫管理システム。
導入の手軽さとシステムとしての柔軟性の高さが強みで、頻繁なアップデートにより常に機能が進化している。たとえば、トータルピッキングしてきた商品を発送先別に棚やカゴなどに分ける作業（種まき方式）に対応する画期的な機能など、豊富な機能を備えている。
コマースロボティクスは自らがECサイトを多数運営し、月間50,000件以上出荷する物流プロ集団とあって、導入・運用におけるサポート体制も万全。物流技術管理士の有資格者が多数揃っていることから、現場のオペレーションの知見やノウハウをもとに、自社の状況にあわせた最適なカスタマイズを提案してくれるのも心強い。
- 料金：月額10,000円〜、初期費用35,000円
COOOLa（株式会社ブライセン）
クラウドトーマス（株式会社関通）
年間1,100万個以上の商品を出荷している物流会社が開発した、 クラウド型の倉庫管理システム。「ネクストエンジン」「CROSSMALL」「shopify」など、国内・海外の様々なカート、モール、OMSに対応など、導入後の｢使う」を基軸にしている。
在庫、入荷、出荷データの一元管理が可能で、複数の物流倉庫があっても、PC、スマホ、タブレットがあれば、どの拠点からも同じデータを確認することが可能。従来のハンディターミナルを使用せず、スマホにアプリをインストールして使用できるため、運用開始が簡単にできる。
また、送り状をピッキングリストとして出荷作業を行うことができるので、物流現場のペーパーレス化も実現できる。
ONEsLOGI/WMS Cloudサービス（日立物流ソフトウェア株式会社）
国内3PL分野の先駆者である日立物流グループが手掛ける倉庫管理システムで、物流現場での経験と実績を結集させている。世界24の国と地域への導入実績があり、様々なニーズに対応した物流ソリューションサービスとして生産性向上と物流品質改善に寄与。多業種に対応したシステムを低コストで提供しているところが魅力。
庫内運用に必要な入荷管理機能、在庫管理機能、出荷管理機能を標準機能として実装している。ピッキングや棚卸作業の平準化により、在庫管理精度・作業精度向上を実現。
また、通販物流対応として、名寄せ・同梱機能・誤配送防止機能を標準装備。APIによるシステム連携や基幹系システムとの連携も可能なので、物流に関わる業務全体の効率化も期待できる。
主な物流管理システム（EC物流向けWMS）
ロジザードZERO（ロジザード株式会社）
mylogi（アートトレーディング株式会社）
EC事業者によって開発された倉庫管理システムで、EC事業者の視点に立った機能を揃えている。多品種小ロットのECの在庫管理に適していて、誰でも使いやすいシンプルな画面操作と業務フローが特徴。最大の特徴は主要EC受注管理システムとの連携。
注文連携から出荷まで、受注・物流一体化のシステムとなっているため、楽天、Amazon 、shopify 、MakeShopなどモールシステム・カートシステムのAPIを通して注文を自動取得しmylogiへの取込み・引当てが可能。
また、在庫がある注文は自動で出荷作業の開始完了が可能で、出荷完了メールを自動送信できるので、人手のかかる作業を極限まで抑えられる。
- 料金：月額30,000円～、初期費用100,000円～
SunLOGI（株式会社サンシーア）
ECサイトの受注管理・倉庫管理に特化した物流管理システム。大規模開発実績を大量にもつ、システム会社が開発した物流システムで、マクロ機能やカメラ検品など、常に最新のAI技術アップデートが可能。
Webシステム運用・保守ノウハウを生かしたシステム全体の安定性・可用性が特長。ユーザー視点に立った、シンプルで利用しやすいシステム画面で、業務で利用する機能だけを使いやすいボタン配置で提供。作業の標準化によりミスを減らし、作業効率のアップと業務の属人化解消が期待できる。
複数のカートやモールに自動連係し、出荷を自動化できる点や、自社EC店舗でのテスト運用、大手倉庫業との連携開発による低コストでのサービス導入といった点もメリットといえる。
- 料金：月額10,000円（1倉庫・1荷主）、初期費用なし
主な物流管理システム（その他業種特化型WMS）
Super-Vision（株式会社東計電算）
POT Manager V2.0（アイニックス株式会社）
（出所：POT Manager V2.0公式Webサイト）
食品雑貨等の3PLに最適なフレキシブルな倉庫管理システム。EDI接続によるデータ入力の効率化、モバイルターミナルによる誤出荷の防止、配車管理システムによる配送効率の向上など、３PLや中小規模の倉庫管理に適した機能を多く備えている。
倉庫内の保管料請求（坪貸し）や数量、重量、容積による荷役請求などの債権管理もできるようになっており、1システムで複数の荷主が管理できることが特徴で、荷主ごとにシステムを用意する必要がなく経済的。入荷日・出荷日・納品日等のバッチ管理や、製造ロット、賞味期限による入荷・出荷の検品、期限前のアラートも作成できて食品業界に適したサービスとなっている。
無線式のモバイルターミナルは強い落下強度や防塵・防水仕様と大容量バッテリ、2.8インチ大画面表示とポケットサイズながら高機能であることも魅力。
- 料金：2,500,000円（基本パッケージ）
主な物流管理システム（パッケージ型WMS）
倉一朗 Ver.6（システムギア株式会社）
物流センターにおける、入荷・在庫・帳票類の発行・出荷・請求などを一元管理し、業務の効率化をサポートする倉庫業に特化した販売管理システム。倉庫業特有の商習慣である1～3期締めによる保管料を荷主に合わせて設定でき、各種計算の適用日を指定できる。
入庫は「荷主」「商品」「倉庫」「ロケーション」の各種マスタを利用しながら情報を入力、予定外の新たな商品にもそのまま登録対応できてストレスフリーなのも嬉しい。
荷主毎の商品在庫状況は任意の日付で画面確認でき、スピーディーに対応可能、在庫数調整や荷主間移動、在庫なしアラートといった倉庫業の必須機能を網羅している。
在庫らくだプロ22（株式会社BSLシステム研究所）
主な物流管理システム（その他倉庫業務を効率化）
barcorrect（株式会社アトムエンジニアリング）
通販の出荷や倉庫などの出荷現場で行われる出荷検品業務を、正確・スピーディーに作業するためのクラウド検品システム。
「既に販売管理などで在庫管理を行っているが検品精度を上げたい」「在庫管理システムを導入するほどの物量はないが出荷検品で誤出荷を防ぎたい」などのニーズにも対応したシステムとなっている。
受注データに対する出荷検品や、入荷予定に対する入荷検品において、バーコードを読み取り照合することで誤出荷を防止。リアルタイムでの進捗確認や賞味期限のチェック検品機能も特徴的。CSV形式のデータとの連携は、受注データ・生産指示データなど幅広い種類のデータをインポート・エクスポート問わず使用でき、作業が煩雑にならないことも魅力のひとつ。
LogiPull（株式会社シーイーシー）
荷物の積卸しのためにトラックを停車する「トラックバース」の予約を軸に、トラックの待機時間を削減させるためのシステム。
トラックバース予約を受け付け、管理する機能をWebシステムとすることで待機時間の削減、待機渋滞の緩和、事前把握で入出荷準備という効果が期待できる。GPS連携によってリアルタイムに車両の位置情報を把握でき、到着予測時間がわかるためバースを効率良く活用できる。
また、事前予約がない場合でもタブレットでの当日受付を可能にし、予約状況に合わせて適切な時間にバースへ案内できるようになっているので、柔軟に対応できる点も良い。トラックバースの利用時間や荷積み・荷降ろし時間を記録するシステム「バース実績管理システム」利用すれば、作業改善分析用にデータを記録するほか、トラックスケールと連携した積み荷重量の記録も可能となっている。
MMLogiStation（株式会社YEデジタル）
倉庫管理システムと、倉庫内の設備に関してリアルタイム制御を行う倉庫制御システムの中間で、「物流現場の制御・管理に特化」した倉庫自動化システム。自動化設備の制御部分を倉庫管理システムと切り離し、柔軟な設備構成、作業フローを作れるようになっている。
各システムの役割がシンプルとなっているため、自動化設備の導入や作業手順の変更等、業務の変化にもスピーディーに対応可能。メーカー問わず主要な自動化設備の連携パーツを「作業オペレーションデザイナー」上で使用できるプラグインとして提供し、作業フローを構築。倉庫内のすべてのオペレーションを把握できるため、ダッシュボードから実績の可視化・分析が可能。
課題がある場合、「MMLogiStation Analyst」のデジタルツイン・シミュレーションを使い、ボトルネックの特定と解決につなげることができる。
コメント