こんにちは、SCSK株式会社の池田です。 前回は、AWSで可用性を上げるために「 LifeKeeper 」が有効であることをお伝えしました。４回目の今回は、AWS環境でLifeKeeperを使ったHAクラスタを構成する際の接続方式についてお伝えします。 なぜAWS(パブリッククラウド)でLifeKeeperが有効なのか！ パブリッククラウドでシステムを構築すれば耐障害は万全という間違った思い込み。AWSを初めとするパブリッククラウドでなぜLifeKeeperが有効なのかを解説します。 blog.usize-tech.com 2023.11.29   AWSでは仮想IPアドレスが設定できない！？ 第１回「 HAクラスタウェア「LifeKeeper」で可用性を高めよう！ 」でもお伝えした通り、オンプレミス環境や仮想環境(vSphere)では、仮想IPアドレス(Virtual IPアドレスとも言います)に接続することで、利用者はどちらのサーバに接続しているかを意識する必要がありませんでした。 しかしながら、AWSでは仮想IPアドレスの機能が提供されていません。 ではLifeKeeperでは、どのようにして冗長化されたサーバへの接続を実現させているのでしょうか？ 今回は、LifeKeeperで用意されている接続方式にどのようなものがあるかについて説明します。 AWSでは仮想IPアドレスの機能がないのね 仮想IPアドレスに代わる２つの接続方式 LifeKeeperには、仮想IPアドレスに代わる接続方式が２つ用意されています。 今回お伝えする２つ以外の方式もありますが、それらの接続方式が使用されるケースは非常に稀な為、割愛します。 1．ルートテーブルを使用した接続方式 まず一つ目はルートテーブルを使用した接続方式です。 先述した通り、AWSでは仮想IPアドレスの機能が提供されていません。 その為、LifeKeeperを構成するサーバが存在するVPCのCIDR外に「ダミーの仮想IPアドレス」を用意し、その「ダミーの仮想IPアドレス」と「稼働系サーバのENI」をルートテーブルで紐づけることによって、稼働系サーバにアクセスできるようにする接続方式です。 この方式については、LifeKeeperに同梱されている「 Recovery Kit for EC2 」というオプション製品で実現できます。 イメージ図は以下の様になります。   （１）クライアントは「ダミーの仮想IPアドレス」（図では10.1.0.10）にアクセスします。 （２）ルートテーブルには予め「ダミーの仮想IPアドレス」のTargetとして稼働系サーバのENI（図では10.0.2.4）を 指定しておくことによって、クライアントからの通信が稼働系サーバに送信されます。 （３）障害が発生しフェイルオーバ処理が必要となった際には、LifeKeeperの機能(AWS CLIが自動実行)により、 ルートテーブルの「ダミーの仮想IPアドレス」のTargetが待機系サーバのENI（図では10.0.4.4）に書き換えられます。 このイメージ図では、クライアントはLifeKeeperを構成するサーバが存在するVPC内に存在していますが、AWS Transit Gatewayを組み合わせることによって、VPC外（オンプレミスや別のVPC）のクライアントからの通信にも対応できます。 この構成については、また別の機会にご説明します。 ２．Route53を使用した接続方式 もう一つの接続方式はAmazon Route53（以下、Route53）を用いるものです。 Route53はご存じのかたも多いと思いますが、AWSが提供するグローバルに分散されたDNSの機能です。 Route53のAレコードには、稼働系ノードのIPアドレスを指定しておくことで、稼働系サーバにアクセスできるようにする接続方式です。 この方式については、LifeKeeperに同梱されている「 Recovery Kit for Route53 」というオプション製品で実現できます。 イメージ図は以下の様になります。 （１）クライアントはホスト名(図ではscsk.jp)でクラスターにアクセスし、Amazon Route53で名前解決を行い、 名前解決したIPアドレスで稼働系サーバにアクセスを試みます。 （２）Amazon Route53のAレコードには、稼働系サーバのIPアドレス（図では10.0.2.4）を指定しておくことで、 クライアントからの通信が稼働系へ送信されます。 （３）障害が発生しフェイルオーバ処理が必要となった際には、LifeKeeperの機能(AWS CLIが自動実行)により、 Amazon Route53のAレコードを待機系サーバのIPアドレス図では10.0.4.4）へ書き換えることで、 以降のクライアントからの通信は10.0.4.4へ到達します。 まとめ 今回は、AWSにおける２つの接続方式についてご説明しましたがいかがでしたでしょうか？いずれの方式もサイオステクノロジーからARKが提供されているので、比較的容易に構成することができますね。 まとめますと ・AWSで仮想IPアドレスの機能が提供されていない ・仮想IPアドレスに代わる接続方法としては、主にルートテーブルとRoute53を使用した方法がある ・２つの接続方式を実現する為のARKがサイオステクノロジーから無償で提供されている。 次回は、今回お伝えした2つの接続方式について、どのような構成の場合にどちらの方式を選択するかについてお伝えします。お楽しみに！！

こんにちは、SCSK株式会社の池田です。 前回は、「 LifeKeeper 」のオプション製品であるARKに焦点を当てて解説しました。３回目の今回は、LifeKeeperがAWSを代表とするパブリッククラウドで有効な理由についてお伝えします。 「LifeKeeper」で可用性を高められるミドルウェアはこれだ！ HAクラスタウェアのLifeKeeperについて、どんなミドルウェアの可用性を高めることができるのか？またオプション製品であるARKの仕様の概要についてお伝えします！ blog.usize-tech.com 2023.11.20   パブリッククラウドの責任共有モデルって知ってますか？ たまに「AWSに移行したら、全部AWSにお任せで良いんでしょ？」って声を聞くことがありますが、実はAWSを代表とするパブリッククラウド事業者と利用者とで、機能要件・非機能要件における機密性、完全性、可用性について明確に責任が別けられているってご存じでしたでしょうか？ 以下がAWSが公開している「責任共有モデル」を図示したものになりますが、「お客様」と「AWS」とでキレイに責任範囲が別けられています。 一例でご説明すると、サーバやストレージといったハードウェアの障害については、全てAWSが責任を持って可用性を担保してくれますが、上記の図のように、「お客様」担当範囲のレイヤについては、利用者側で責任をもって可用性を考慮する必要があるんです！ 例えば、アプリケーションで障害が起きても、AWSの責任範囲ではないので、利用者側でアプリケーションの可用性を担保しておく必要があります。 パブリッククラウドは万能だと思っていたけど、意外と盲点だったわ ここでLifeKeeperの登場！ そこで登場する強い味方が LifeKeeper なのです！ LifeKeeperを導入することでアプリケーションを保護し、またEC2インスタンスを別AZに配置することにより、万が一のAZ障害にも耐えうる構成とすることができます。 AWSの公式アイコンで表現するとこんな感じになります。 まとめ 今回は、AWSの責任共有モデルを参考に、アプリケーションのレイヤについては、利用者の責任で可用性を担保する必要があることをご説明しました。 ・パブリッククラウドには責任共有モデルがある ・アプリケーションレイヤは利用者の責任範囲となっている ・パブリッククラウドはアプリケーションレイヤの可用性は担保しない ・LifeKeeperはアプリケーションレイヤの可用性を高めることができる 次回は、AWSにおいて、どのような接続構成を取ることができるのかについてお伝えします。お楽しみに！！

前回記事は、パブリッククラウド環境をCatoクラウドへ接続する方法として、vSocketとCross Connectを比較してみました。   vSocket × Cross Connect 徹底比較 パブリッククラウドをCatoクラウドへ接続する方法「vSocket」と「Cross Connect」を性能面・コスト面等から比較します。 blog.usize-tech.com 2023.11.29   続いて、本記事では実際にAWSをCross ConnectでCatoクラウドに接続する際の流れをご紹介します。 各パブリッククラウドの接続手順は、以下のCato Knowledge Baseもご参照ください。   Cato Knowledge Base | Cato Cross Connect Sites   まずは構成を決める 接続ロケーションを決める AWSのDirect Connectロケーションと、CatoのCross Connectロケーションを照らし合わせ、利用するロケーションを2つ選択します。 AWS Direct Connect Locations Cato Knowledge Base | Cato Cross Connect Availability 2023年11月現在、日本国内のCross Connectロケーションは以下2つのみですので、AWSの東京または大阪リージョンを利用する場合には、この2つを選択します。 Equinix TY2, Tokyo, Japan Equinix OS1, Osaka, Japan ネットワーク構成を決める 続いて、ネットワーク構成を検討します。構成イメージとしては、Transit Gatewayを使うパターンと使わないパターンが考えられます。選択のポイントは、 接続したいVPCが(将来の拡張も含めて)いくつあるか です。 構成例A : Transit Gatewayを利用しないパターン Direct Connect Gatewayに接続できる VPCの上限が20 です。 VPC同士のDirect Connect Gatewayでの折返し通信は、基本的には対応していません。※詳細はAWS側の仕様をご確認ください 構成例B : Transit Gatewayを利用するパターン Transit Gatewayに接続できるアタッチメントの上限が5,000です。 Direct Connect Gatewayに接続できるTransit Gateway の上限が6です。 上記2点より、 たくさんのVPCを接続する構成が可能 です。 Transit GatewayでVPC同士の折返し通信ができます。※通信させない構成も可能です 構成例Aと比較し、 Transit Gatewayおよびアタッチメントの利用料金が発生 します。 なお、構成例Aで構築した後にBに変更することも可能ですが、その際は、AWS側の設計変更や構成変更時の通信断が発生します。 ASNを割り振る 各仮想プライベートゲートウェイ(VGW)、Direct Connectゲートウェイ(DXGW)、トランジットゲートウェイ(TGW)と、Cato側の設備はBGPで経路交換を行うため、重複しないAS番号(ASN)を割り当てる必要があります。 なお、Cato側のASNは2byte(64512～65535)のみ対応しておりますが、4byte ASNとのピアリングに対応しているため、AWS側のASNは2byte、4byte(4200000000～4294967294)のどちらでも可能です。 Direct Connect接続部分のIPアドレスを決める Direct Connect の両端に、接続セグメントを作成します。 具体的には、社内ネットワークで利用されていないIPアドレスレンジから、/30のIPアドレスレンジを2つ割当し、Cato側・AWS側のIPアドレスを決めます。 例として、検証用に構成を作成し、ASNとIPアドレスを割り当てた図が以下です。 以上で、構成が確定です。 Cross Connect用Siteを作成する 続いて、Cato Management Consoleから、Cross Connectで接続するSiteを作成します。 作成方法は通常のSiteと同じですが、 Connection Type は 「Cross Connect」を選択 します。 この時点ではSiteを作成するのみでOKです。他の設定はDirect Connectの開通後に行います。 必要情報をCatoパートナーへ連絡する ここまで準備ができたら、実際にDirect ConnectをCato側から接続してもらうよう、以下の必要情報をCatoサービスの提供元へ連絡します。   項目 説明 記載例 1 対象のCato Site名 手順2で作成したSite名 CrossConnectAWS 2 接続するパブリッククラウド AWS/Azure/GCP/ Oracle Cloud AWS 3 パブリッククラウドのアカウントID 上記のアカウント AWSアカウント(数字12桁) 4 パブリッククラウドの利用リージョン メインで利用されるリージョン ap-northeast-1(Tokyo) 5 Primary Linkのロケーション 手順1で選択したもの Equinix TY2, Tokyo 6 Secondary Linkのロケーション 手順1で選択したもの Equinix OS1, Osaka 7 接続帯域 回線帯域 1Gbps 申請後、接続が準備されるまでに必要時間は、ロケーションによって異なります。1.のCross Connectロケーション一覧に納期の目安が書いてありますので、ご参照ください。2023年11月現在は日本ですと2週間程度となっています。 接続が準備され次第、パートナーから完了の連絡があります。 AWS側の設定を行う パートナーから準備完了の連絡を受けたら、AWS側・Cato側それぞれに設定を行っていきます。 なお、以後の手順はすべて、前述の 「構成例A Transit Gatewayを利用しない」パターンでの例 となります。 Direct Connect接続をAcceptする AWSコンソールの「Direct Connect」を確認すると、以下のように接続が準備されています。 状態がorderingとなっており、承諾待ちの状態です。IDをクリックすると「承諾する」ボタンがありますので、これをクリックして接続を承諾します。 2回線それぞれ承諾します。 しばらくすると状態が「available」になります。 Direct Connect Gatewayを作成する 設定項目は名称とASNのみです。ASNは手順1で決めたものを指定します。 この手順は、新規の環境を想定した例となっています。すでに各VPCで仮想プライベートゲートウェイ(VGW)を利用し通信を行っている場合、これ以降の作業により既存の通信が切断される可能性がありますので、十分にご注意ください。 Direct Connect Gatewayと仮想プライベートゲートウェイを紐付けする 作成したDirect Connect Gateway(以下DXGW)をクリックし、「ゲートウェイを関連付ける」に進みます。 紐付ける仮想プライベートゲートウェイ(以下VGW)をすべて選択します。 また、「許可されたプレフィックス」は、Cato側にBGPで広報するルートとなります。空欄にした場合には、各VPCのアドレスレンジが自動で広報されますので、特に要件がなければ空欄で問題ありません。 仮想インターフェイスを作成する Primary、Secondaryそれぞれの接続に対し、仮想インターフェイス(以下VIF)を作成します。 以後、AWS側・Cato側でそれぞれ設定を行っていきますが、お互いがお互いを「Peer(ピア)」と呼ぶので、IPアドレスやASNの設定項目がCato側を指しているのかAWS側を指しているのかを間違いやすいです。作成した構成図を見ながら作業されることをおすすめします。 以下に設定項目の例を掲載します。 タイプ VIFをDXGWへ接続する場合は「プライベート」を選択 仮想インターフェイス名 任意の名前を入力 接続 VIFを作成するDirect Connect接続をプルダウンで選択 仮想インターフェイスの所有者 通常は「自分のAWSアカウント」 ゲートウェイタイプ DXGWへ接続する場合は「Direct Connect ゲートウェイ」を選択 Direct Connect ゲートウェイ 先ほど作成したものをプルダウンで選択 Virtual Local Area Network 元となるDirect Connect接続のVLANと同じ番号を指定 BGP ASN 手順1で決めた Cato側の ASNを指定 上記まで入力したら 「▶追加設定」をクリック して下に進みます。 ここを忘れがちです。 アドレスファミリー IPv4を選択 ルーターのピアIP Cato側の IPアドレス AmazonルーターのピアIP AWS側の IPアドレス BGP認証キー 任意の文字列 ※設定必須 ジャンボMTU チェックを入れない (Catoは非対応) SiteLinkの有効化 チェックを入れない (Catoは非対応) すべて設定したら作成ボタンを押します。Primary/SecondaryそれぞれのVIFを作成したら、AWS側の設定は完了です。 CatoのSite側の設定を行う 続いて、Cato側の設定を行います。 Cross Connectを設定する Network > 対象Site  > Cross Connect の設定項目にて、Primary/Secondary の接続情報を設定します。手順1での設計どおりIPアドレスを設定します。また契約帯域に合わせたBandwidthを指定します。 設定後、Saveします。CatoとAWS間の疎通にしばらく時間がかかるため、次へ進みます。 BGPを設定する 続いて、Cato側のBGP設定を行います。左メニューの「BGP」から「New」をクリックして設定を作成します。PrimaryとSecondaryの2つの設定が必要です。    Name 任意の名前を指定 ASN Settings Peer 手順1で割り当てた AWS側の ASN (この構成だとDXGWのASN) ASN Settings Cato 手順1で割り当てた Cato側の ASN Peer AWS側 のIPアドレス 続いてBGP Policyの設定です。こちらはCatoおよびAWS内のルーティングに応じて設定する必要があります。 Advertise AWS側に対してどのようにルートをアドバタイズするかの設定です。 Default routeにすると、0.0.0.0をアドバタイズします。 もしAWS側で0.0.0.0を他に向ける必要がある場合には、All routesまたはSummary routesのアドバタイズをご検討ください。(※) Accept AWS側からのRouteを受け入れるかどうかです。 通常はチェックを入れます。 チェックを入れ忘れると、AWS側のルートをCatoで受け取らなくなってしまうので注意してください。 NAT CatoからPeer宛の通信において、送信元IPアドレスをNATするかどうかです。 チェックを入れた場合には、送信元IPがCato側のPeer IPアドレスに変換されます。 ※AWSの場合受け取れるルート数の上限があります。All routesをアドバタイズすると上限を超えがちなため、ご注意ください。(2023年11月現在は上限100ルート) MD5 Auth AWS側で設定したのと同じBGP認証キーの文字列を入力。入力必須です。 Metric 低い値の経路が優先されますので、値をPrimary<Secondaryとするのが一般的ですが、Cato側で自動でPrimary側が優先されるため、Metricを同じ値にしても正常に動作します。(優先度の詳細は後述します) Hold time デフォルト値で問題ありません。もし接続先のクラウド側で指定があればそれに従ってください。 Keepalive interval Email Notification BGPピアがDown/Upした際にEメールで通知する機能です。接続監視のため設定されることをおすすめします。 PrimaryとSecondary両方のBGP設定を作成したら、Saveします。 以上で設定は完了です。 接続テストを行う 続いて接続が正常にできるかのテストを行います。 Connectivityのテスト 先ほど設定したCross Connect のページで「Test Connectivity」ボタンをクリックします。Cato側からAWSに対し、ICMPでの疎通テストが実行されます。 以下のように「 Success! 」と表示されたら接続成功です。もし「Failed!」やその他エラーとなる場合は、アドレス設定がAWS側の設定と相違ないかを確認します。 BGPのステータス確認 BGPの設定画面で、「Show BGP Status」をクリックすると、BGPの状態が確認できます。 BGP Status BGP の接続状態です。「Established via ～」となっていれば正常に接続できています。 「Not Established」やその他表示の場合、BGP Peerが張れていません。IPアドレスやASNが正しく設定されているか、BGP認証キーがAWS側と一致しているかを確認します。 Routes from neighbor AWS側から受け取っているルートです。 ここが空欄の場合、BGP設定でAcceptのチェックが外れている可能性があります。 Routes to neighbor AWS側へ渡しているルートです。BGP設定のAdvertiseで設定したルートが渡されます。 Catoルートテーブルの確認 Monitoring > Routing Table で、AWS内のルートを受け取れていることを確認します。 VPCのIPアドレスレンジが「DYNAMIC」で受け取れていれば正常です。 図のように、通常時は同じルートが2つあり、Secondary Linkから受け取っているルートはグレーアウトしています。Primary Linkが障害等でDownした場合には、自動でPrimaryのルートが消え、Secondaryのルートが有効になります。 AWS側のルートテーブルを設定・確認する 続いて、AWS側のルートテーブルを確認します。この検証構成ですと、サーバがいるサブネットのルートテーブルを確認します。 AWSのルートテーブルでは、BGPで受け取ったルートをルートテーブルに自動反映するか、しないかを設定することができます。上記の「ルート伝播の編集」の箇所です。 デフォルトは、伝播が「いいえ」になっており、自動反映はされません。どちらにするかは、サブネット内のルーティング要件に合わせて検討します。 今回は伝播を確認するために「はい」に設定しました。すると、ルートが以下のようになります。 「伝播済み」が「はい」となっているルートが、Cato側から自動反映されたルートです。今回はCatoからAWSへDefault routeとAll routesを広報しており、それがAWSのルートテーブルに反映されていることがわかります。 以上ですべての設定が完了です。セキュリティグループ等を確認の上、Cato網からAWS上のホストへ疎通が通ることを確認します。 その他補足情報 障害テストの実施 Direct Connectでは、仮想インターフェイスのメニューから、BGPの障害テストを行うことができます。 この方法で、Primary Linkに擬似的に障害を発生させ、Secondary Linkへの切り替わりを試験することができます。 今回構築した検証環境で試したところ、以下のような結果になりました。通信先(172.16.0.29)はAWSのEC2、通信元は別SiteのSocket配下にあるWindows PCです。 切り替え前 : 172.16.255.1(Primary LinkのAWS側アドレス)を経由していることがわかります。 疑似障害発生 : Pingを打ち続けた状態で、前述のAWSの障害テストを行いました。Pingが止まった後、数秒で再開しました。 切り替わり後 : もう一度Tracerouteしたところ、172.16.255.5(Secondary LinkのAWS側アドレス)を経由して到達しています。経路が切り替わっていることがわかります。 このように、構築後には障害テストを実施することをおすすめします。 Primary/Secondaryの優先度について Cross Connectにおいては、Primary/Secondary Linkの優先度は、常にPrimary側が優先されるようCato側で制御されています。優先度はRouting TableのMetric Infomationから確認可能です。 Tunnel Metric(値が低いほうが優先)が、Primaryが5、Secondaryが10に自動設定されており、この値は変更することができません。 その下のWeightは、BGP設定の「Metric」で指定した値が反映されますが、経路選択においてはWeightよりもTunnel Metricが優先されるため、影響を与えることができません。 このため、 両方のLinkをActive/Activeで利用することはできません。 まとめ 以上、長くなりましたが、AWSでのCross Connect接続方法のご紹介でした。 他のパブリッククラウドでも、おおよその流れは同じになりますので、参考にしていただけますと幸いです。

今回は、パブリッククラウドをCatoクラウドへ接続する際の方法についてのご紹介です。 現在、Catoクラウドをご利用中・ご検討中のお客様のほとんどが、社内システムの一部または大半をパブリッククラウドに置かれており、クラウド環境をどのようにCatoと接続するかご相談をいただきます。 AWS・Azure・GCP等のパブリッククラウドをCatoへ接続する方法は、2023年11月現在、以下の3つがあります。   接続方法 対象環境 主な利用シーン 1 vSocket AWS/Azure/VMware ESXi 通常の場合 2 Cross Connect AWS/Azure/GCP/Oracle Cloud 高スループット・大容量通信を必要とする場合 3 IPSec すべての環境 1および2が利用できない場合 (機能制約が多いため) 通常は、最も手軽な方法として、vSocketでの接続方法をおすすめしておりますが、パブリッククラウド上のシステム数が多い場合や、高スループット・大容量通信を必要とする場合には、2番のCross Connectも合わせてご提案しております。 本記事では、このvSocketとCross Connectを、性能・コスト・その他の面で比較していきます。 なお、Cross Connectがどういったサービスなのかは、以下の記事にて詳細に解説しております。 Catoクラウド の Cross Connect について Catoクラウドの Socket/vSocket、IPsec以外の拠点接続方法である”Cross Connect”について紹介します。 blog.usize-tech.com 2023.08.25 また、別記事にて、Cross Connectの実際の設定方法をご紹介しておりますので、あわせてご参照ください。 Cross ConnectでAWSをCatoへ繋いでみよう AWS上のVPCをCatoクラウドのCross Connectで接続してみます。CatoとAWS Direct Connect、両方の設定の流れをご紹介します。 blog.usize-tech.com 2023.11.29 Cross Connectとは? CatoクラウドのCross Connectとは、 パブリッククラウドとCatoを仮想の専用回線で接続するサービス です。 具体的には、AWSのDirect Connectや、AzureのExpress Routeを利用し、クラウドエクスチェンジ経由でお客様のクラウド環境をCatoへ接続します。 vSocketがInternetを経由した暗号化通信を行うのに対し、 Cross Connectは仮想専用回線を利用するため暗号化が不要となり、より低遅延・高スループットの通信が可能 です。 このため、パブリッククラウド上に 高速な応答が求められるシステムを設置されている場合や、大容量の通信が想定される場合には、Cross Connectをおすすめ しています。 なお、Cross Connectは原則、最小契約帯域が501Mbps以上、2回線での冗長利用となります。詳細はご相談ください。 vSocket vs Cross Connect レスポンス比較 では、実際にどのくらいレスポンスが違うのでしょうか。vSocketとCross Connectで環境を構築し、応答時間を検証してみました。 条件 AWS東京リージョンに接続 vSocket・Cross Connectともに、Catoの帯域は1Gbpsで接続 Cato Clientで接続したSDPユーザから、VPC内の仮想サーバに対し32byteのPingを1000回実施 結果 接続方法 測定したラウンドトリップタイム vSocket 最小 = 29ms、最大 = 41ms、 平均 = 33ms Cross Connect 最小 = 17ms、最大 = 25ms、 平均 = 20ms 確かにCross Connectのほうがラウンドトリップタイムが短い、つまりレスポンスが早いという結果が得られました。 実際の通信においては、体感速度は様々な条件に左右されますが、少なくともIPレベルではCross Connectが有意に早いと言えそうです。 vSocket vs Cross Connect 費用比較 続いて費用面ではどうでしょうか。 専用線接続は一般的に基本利用費用が高額ですが、データ通信量が従量課金となっているパブリッククラウドの場合には、通信量が多いと専用線のほうが低コストになる場合があります。 では単純にパブリッククラウドの利用費用だけを比較した場合、vSocketとCross Connectでどのくらいの差があるのか、またどのくらいのデータ通信量があればコストが逆転しそうか、AWSの場合で計算してみました。 前提条件 AWSの東京リージョンを利用し、vSocketはHA構成、Cross Connect(AWSの場合Direct Connect)は1Gbpsの冗長構成とします。1ヶ月=730時間の計算です。 ※費用はすべて2023年11月現在のものです。あくまで机上の計算であることをご了承ください。 vSocketの月額概算費用 用途 サービス 単価(USD) 1ヶ月費用(USD) 備考 vSocket EC2 c5.xlarge ×2台 0.214/1時間 312.44 On-Demand料金 vSocket EBS gp2 16GiB×2台 0.12/GB・1ヶ月 3.84   データ通信量 アウトバウンド通信 0.114/GB ???   合計     316.28 + データ通信量   ※Saving Plansやリザーブドインスタンスを利用することにより費用削減可能です。 ※2024年2月より、IPv4 Global IPアドレスに対する費用が発生します。vSocket1台につき2つのGlobal IPアドレスを使用するため、その分の費用が追加発生します(4IPで約14.6USD/月)。 Direct Connect(専用線利用)の月額概算費用 用途 サービス 単価(USD) 1ヶ月費用(USD) 備考 Direct Connect ホスト型 1Gbps×2回線 0.314/1時間 458.44   データ通信量 アウトバウンド通信 0.041/GB ???   合計     458.44 + データ通信量   ※複数VPCがありTransit Gatewayを必要とする場合には、その利用料金が別途必要です。 比較結果 上記のとおり、データ通信量を除くとDirect Connectのほうが142.16USD分高コストとなります。 しかし、データ通信量の単価はDirect Connectのほうが安いので、一定量以上の通信量が発生するとコストが逆転します。この逆転の目安を計算すると、おおよそ2TB/月となりました。 つまり この条件においては、AWS⇒Catoのデータ通信量が月間2TBを超える場合にはDirect Connectのほうが安価 、2TBを超えない場合にはvSocketのほうが安価です。費用比較のひとつの目安にできるかと思います。 ※費用体系は各パブリッククラウドサービス(AWS/Azure/etc…)ごとに異なりますのでご注意ください しかしながら、 Direct Connectには前述のとおりスループット等性能面でのメリットがあるため、実際にはこれらも踏まえて比較検討 することになるかと存じます。 その他比較 また、vSocketとCross Connectでは他にも以下のような差異があります。 Cross ConnectではvSocketの運用が不要 vSocketは仮想アプライアンスですので、ユーザ側での構成管理やセキュリティグループ等のセキュリティ管理、またvSocketのファームアップがあったりと、仮想マシンとしての運用が発生します。 対してCross Connectは仮想マシンを持たないため、これらの運用が不要です。 Cross Connectでは利用できない機能もある Cross ConnectはSocketを持たず、かつインターネットを通らない接続のため、以下の機能は利用できません。 Local Routing / LAN Firewall Backhauling Bypass Local Port Forwarding 上記機能はいずれも、パブリッククラウドで利用するシーンはあまりないため、利用上の影響は少ないかと思います。 まとめ CatoクラウドのCross Connectは、vSocketとは異なり、仮想的な専用回線を使用しInternetを経由せずにCatoへ接続するサービスで、 利用をおすすめする場面は、主に下記2つです。 パブリッククラウド上に、高速な応答が求められるシステムを設置されている場合 パブリッククラウドから拠点/ユーザに対する通信量が多い場合 (AWSの場合はおよそ2TB/月目安) SCSKには、Catoクラウドとパブリッククラウド、両方に精通したエンジニアが多数おりますので、どちらにするかお悩みの際はぜひご相談ください。

はじめに こんにちは。SCSKのふくちーぬです。 今回は、AWS Resource Groupsのライフサイクルイベントを使用して、リソースに一意に付与している共通タグの変更検知をしてみます。 AWS Resource Groupsは、AWSクラウド上のリソースをカスタムグループにまとめるためのサービスです。AWS上で散らばったリソースの整理整頓をすることができます。 例として、EC2・セキュリティグループ等の複数リソースがある場合、それらを一つのグループにまとめておくことができます。これによって、関連するAWSリソースを見つけたり、一括で管理したりするのが容易になります。 環境準備 今回は、セキュリティグループとS3を作成します。作成時に、グループとしてまとめるために一意の共通タグも付与しておきます。 タグをつけ忘れた際には、リソース作成後付与することもできますし、Tag Editorを使用して一括で付与することもできます。 タグキー タグ値 RgName test-system これでリソースの作成は完了です。   Resource Groupの作成 グループの作成 今回は共通タグでリソースをグループ化します。”グループリソースをプレビュー”を押下します。 先ほど作成したセキュリティグループとS3が選択されています。 グループ名を入力します。今回は、”test-group”としています。 “グループを作成”を押下します。 グループが作成されました。 グループリソース内のリンクを押下すると、それぞれのマネジメントコンソールに飛ぶことができて便利ですね。 ライフサイクルイベントの有効 この機能を使用すると、グループ内のアクティビティをモニタリングすることができ、Event Bridgeで検知することが可能です。   AWS Resource Groups がライフサイクルイベントの発行を開始 aws.amazon.com Resource Groups グループライフサイクルイベントを有効にする - AWS Resource Groups リソースグループのライフサイクル変更に関する通知を受け取るには、グループライフサイクルイベントをオンにできます。次に、リソースグループは、グループの変更に関する情報を Amazon に提供します。 EventBridgeでは EventBridge、 サービスで定義したルールを使用して変更を評価し、それに基づいて対処で... docs.aws.amazon.com   ライフサイクルイベント有効するために、”オン”に変更します。   10分ほど待つと、”オン”になります。 これでEvent Bridgeとイベントのやり取りができるようになりました。   通知の設定 Event Bridgeを作成する前に、ターゲットとなる(=通知先となる)SNSトピックの作成をしておきます。 SNSトピックの作成 タイプは”スタンダード”としており、他はデフォルト設定としています。 Event Bridgeの設定 Resource Groupsのライフサイクルイベントについても、CloudTrail等のイベントの構文と記述方法は同様となります。 イベントルール内のイベントパターンの構文に迷ったら、AWSドキュメントのサンプルを参考にしてください。 Resource Groups ライフサイクルイベントの構造と構文 - AWS Resource Groups のライフサイクルイベントは、以下の一般的な形式の JSONAWS Resource Groups オブジェクト文字列の形式をとります。 docs.aws.amazon.com イベントルールの作成 それでは、リソースグループ内のリソースに付与された共通タグに変更があった際にイベントを送信するルールを作成します。   下記のイベントパターンを入力して、イベントルールを作成してください。 　arn内の<AWSアカウントID>には、ご自身のAWSアカウントIDを入力してください。 　対象とするリソースグループは、”test-group”とします。名前が異なる場合は、そちらを入力してください。 { "source": ["aws.resource-groups"], "detail": { "resources": { "membership-change": ["remove"] }, "group": { "arn": ["arn:aws:resource-groups:ap-northeast-1:<AWSアカウントID>:group/test-group"] } } }   “membership-change”を”remove”に設定することで、リソースグループから外れた場合に通知ができるようになります。 検証 今回は、以下の4種類のパターンで検証を行います。 ①共通タグを削除した場合 セキュリティグループの共通タグを削除してみます。 登録したメールアドレスに以下の通知がきます。 意訳すると、「EC2のセキュリティグループがリソースグループのメンバーから削除されました」という意味になります。 またResource Groupsのマネジメントコンソール上でもリソースグループ内から外されていることが分かります。もちろん共通タグを削除しただけなので、セキュリティグループ自体は存在しているので安心ください。 ②共通タグを変更した場合 セキュリティグループの共通タグを付与し直してください。 次に共通タグを変更してみます。ここでは、”test-system-change”に変更しました。 登録したメールアドレスに以下の通知がきます。 内容は先ほどと同様となります。 つまり、共通タグの名前を変更した場合にも”リソースグループから外れた”と判断されることになります。 ③リソースを削除した場合 セキュリティグループの共通タグを修正してください。 では、このセキュリティグループ自体を削除してください。   登録したメールアドレスに以下の通知がきます。 ここまでくると分かっている方も多いと思いますが、上記2パターンと同様の内容ですね。 つまり、リソース自体を削除した場合にも”リソースグループから外れた”と判断されることになります。 ④リソースを追加した場合 最後にリソースを追加してみます。 同様の方法でセキュリティグループを作成してください。 今度は、メール通知が来ないですね。 現在は”membership-change”を”remove”としているためですね。もしリソースグループに新しいリソースが追加された際にも検知したい場合は、以下のように”membership-change”に”add”を追加すれば問題ありません。 { "source" : [ "aws.resource-groups" ], "detail" : { "resources" : { "membership-change" : ["add", "remove" ] }, "group" : { "arn" : [ "arn:aws:resource-groups:ap-northeast-1:<AWSアカウントID>:group/test-group" ] } } } まとめ 検証の内容をまとめます。 特に③において、リソースの削除検知としても利用できないことはないです。 しかし、あくまでResource Groupsの判断基準は「共通タグに変更があったかどうか」で「実際にリソースが存在しているかどうか」まで面倒は見てくれません。 CloudTrailの証跡にて該当リソースの削除APIが実行されたかどうかも併せて判断するのがよいと思われます。 検証 検知の挙動 備考 ①共通タグを変更した場合 リソースグループから外されたと検知される 実際のリソースは存在する ②共通タグを削除した場合 実際のリソースは存在する ③リソースを削除した場合 実際のリソースは存在しない ※リソースの削除をしても検知されるが、削除の確証として使用したい場合にはマネコンでの存在確認/CloudTrailの証跡も併用するのがよい ④リソースを追加した場合 検知されない “membershup-change”に”add”を追加することで検知可能となる 最後に いかがだったでしょうか。Resource Groupsのライフサイクルイベントを使用して一通りの挙動を確認しました。 プロジェクトで各種AWSリソースを指定の共通タグで付与するといったケースが一般的にあります。初期構築時には一意の共通タグを付与したものの、共通タグの変更/リソースの削除・追加オペレーションが発生することは大いに発生します。そんな時に、共通タグの管理方法の一つして導入の検討をしていただければと思います。 本記事が皆様のお役にたてば幸いです。 ではサウナラ～🔥

最近、 SSE と SASE どちらを選択すればよいのか？という質問をいただくことが多いので、改めてSSEとSASEについて説明をします。 まず、結論から先に言いますと、SSE、SASEどちらでも良いと思っています。 ただし、一点注意が必要なのは、 SSEを選択する場合には、SASEをカバーしているSSEを選択される方が賢明 です。 将来的にSASEが必要となった際に、採用したSSEがSASEをカバーしていなければ、導入のやり直しをする必要があるためです。   SSEとSASEについて まず、SSE（エス・エス・イー）は「 Security Service Edge 」、SASE（サッシー、サーシ）は「 Secure Service Access Edge 」の略称です。 ともにアメリカ調査会社であるガートナーが定義（提唱）しており、SASEは2019年に、SSEは2年後の2021年に提唱されました。 2023年6月に当社が独自調査した「国内企業における SASE に関する実態調査結果」を8月に公開しています。 SASEの認知度、実際の導入企業はどれくらいなのか？ SASE に関する実態調査結果とCatoクラウドの認知度について blog.usize-tech.com 2023.09.01 SSE、SASEの認知度（知名度）を調査していますが、SSEの認知度（よく知っている、ある程度知っている）は17.2%で、SASEの認知度は31.6%と、SASEの2年後に登場したSSEより認知度低い状況です。 いずれにしても、SSE、SASE共に7割から8割の方は、よく知らない状況ですので、この記事をご覧の方も、よくご存じない方が多いことを前提に、まずは2019年に登場したSASEについて説明します。 SASEは、ガートナーが2019年8月発行したレポート「 ネットワークセキュリティの未来はクラウドにある （The Future of Network Security Is in the Cloud）」において提唱した、新たなネットワークセキュリティフレームワーク（概念）です。 IaaSやPaaS、SaaSのように言葉があまり浸透していませんでしたが、 NaaS （ナース）「Network as a Service」と、 NSaaS （エヌ・サース）「Network Security as a Service」が統合・融合したものが、SASEとされています。 NaaS + NSaaS = SASE NaaS機能 NSaaS機能 Routing QoS Caching/Content Delivery Traffic Shaping Latency Optimization SaaS Acceleration Geo Restriction etc. Cloud SWG ZTNA/SDP FWaaS Anti-Malware/Next Generation Anti-Malware IPS/IDS CASB/DLP DNS RBI etc. つまり、 SASEとは、ネットワークとセキュリティと統合し、ユーザが場所を問わず企業のシステム、アプリケーション、クラウドサービス、データにアクセスできるよう、安全で信頼性が高く、最適化されたアクセス（接続）を提供すること がコンセプトとなっています。 SASEのアーキテクチャとしては、 SD-WAN （Software-Defined Wide Area Network）、 NGFW （Next Generation Firewall）/ FWaaS （Firewall as a Service）、 SWG （Secure Web Gateway）、 ZTNA （Zero Trust Network Access）/ SDP （Software Defined Perimeter）などから構成されています。 SASEが流行した背景は、業種・業態を問わず、企業の従来のネットワークとセキュリティのインフラの変革期であったためだと言われています。 ハイブリッドワークとクラウドサービス利用の両方のニーズを効率的、かつセキュアにサポートする必要があるためです。 企業のネットワークは、そもそも通信キャリアが提供する専用線、閉域網・MPLS網（Multiprotocol Label Switching）をベースに構成されており、WAN、つまり企業の拠点間を接続することを目的（アーキテクト）としたネットワークインフラに、その後インターネットへの接続するためにネットワークやセキュリティ機器を1つの拠点であるデータセンター（または本社）を出口として集約し、さらにリモートワークをサポートするためのリモートアクセス機器もデータセンター（本社）へ集約することになりました。 その結果、WANのアーキテクチャとは異なる増改築を繰り返さざるを得なくなり、さらに、M365やオンラインストレージ（Dropbox/Box）などのクラウドサービスの利用をサポートするにあたっては、データセンター（本社）内でインターネットの出口分散（M365用のインターネット、Dropbox/Box用のインターネット、、）または、WANが狭帯域（低速）のため拠点からクラウドサービスに直接アクセスさせるLBO（Local Break Out：拠点脱出）をせざるを得ない状況になりました。 インターネットの出口分散やLBOは、きちんとしたセキュリティ検査が行われておらず、アクセス証跡（ログ）保管もきちんと行われていない場合があり、各拠点機器の設定（LBOを含む）は、拠点の担当者に任せるなど、一元管理が行えず、セキュリティインシデントが発生した際に、調査が非常に困難になるなどの課題を抱えることになりました。 つまり、このようなレガシーネットワークや、セキュリティ上の様々な課題、2020年に世界的にコロナウィルスのパンデミックが拡大しリモートワークの機会が増大したことが、SASEのコンセプトに非常にマッチしたため、SASEが流行したと言われています。 2年後の2021年に登場したSSEは、SASEからネットワーク除き、セキュリティ機能のみにフォーカスしたものです。 つまり、 SSEはあくまでもSASEのサブセット（一部分）であり、一般的には、SWG、ZTNA/SDP、CASB/DLP機能のみを指す 場合が多いようです。 ちなみに、ガートナーのSSE定義は、SWG、ZTNA、CASBの3機能になり、DLPやFWaaSは含まれません。 そのため、企業のネットワークインフラであるWANの課題はSSEでは解決ができません。 SWG、ZTNA/SDP、CASB/DLP機能は、あくまでもインターネット接続とリモートアクセスにフォーカスしています。 WANの課題については、通信キャリアが提供するSD-WANや、LBOで解決していることから、まずはSSEの導入を検討される場合があります。 逆に、SSEではなく、最初からSASEを検討されるお客様は、通信キャリア提供するSD-WANを利用されていても、高額であったり、納期が長かったり、ルーティング・NAT・セキュリティポリシーに制限があり、使い勝手が悪いなどの課題を持たれている場合が殆どです。 SSEで実現できること、できないこと SSEとSASEを検討する時、同時にゼロトラストを目指されている方が殆どだと思います。 ゼロトラスト（Zero Trust） は言葉の通り、「何も信用しない」というコンセプトに基づいた概念で、すべてのユーザやデバイス、接続先のロケーションを信用しないものとして捉えます。 通信の暗号化はもちろん、システム、アプリケーション、クラウドサービス、データにアクセスする際は、正当性や安全性を都度検証することをコンセプトとしています。 従来型のセキュリティである 境界型防御 は、「社内は安全」と「社外は危険」とし、その境界にFirewall（UTM）やProxyを設置することで、社外（外部）からの攻撃を防ぐアプローチとなります。 一方で、最近のランサムウェア被害の多くは、この境界であるFirewall（UTM）の脆弱性を狙ったものが殆どであることは説明するまでもないと思います。 インターネット上には脆弱性のある機器がリストアップされており、ある程度の知識があれば誰でも容易に侵入することが可能です。 SSE、SASEを検討されている方は、これまでの境界型防御をやめて、ゼロトラストモデル（ゼロトラストネットワーク・ゼロトラストセキュリティ）を目指されていると思いますが、 残念ながら、SSEではゼロトラストは極一部に限られ、境界型防御をやめることにはなりません 。 SSEで「ゼロトラストネットワークやゼロトラストセキュリティを実現」または「境界型防御からゼロトラストを実現」等は、過剰なマーケティングで、あくまでもデータセンター集約型のセキュリティ境界を、データセンターのFirewall（UTM）からクラウド（SSE）へ移すだけで、境界型防御のままです。 境界型防御のままですが、社外からのリモートアクセスについては、一部ゼロトラストの概念（ZTNA）がサポートされるため、”ゼロトラストアクセス”は実現可能ですが、社内からのアクセスについては何も変わっていませんので、ゼロトラストネットワーク、ゼロトラストセキュリティの実現はできません。 つまり、 SSEは境界型防御をオンプレからクラウドへ移行するソリューション、セキュリティ境界のクラウドリフト セキュリティ上の重要ポイントは、WAN、社内アクセスがそのままなので、拠点間の境界が存在しないことです。 いわゆるランサムウェアを含むマルウェアや攻撃者の水平方向への移動（ラテラルムーブメント）への防御ができません。 SSEで外部からの攻撃の防御力は上がっていますが、企業内ネットワークや、あるいは企業間ネットワークが通信キャリアが提供するレガシーネットワークインフラ（閉域網）のままでは、水平方向の攻撃を防ぐことはできません。 特に、最近の標的型攻撃は、防御力の高い企業を狙うのではなく、サプライチェーン企業（子会社・工場・関連グループ企業等）を狙う サプライチェーン攻撃 が増えてますので、その点でもSSEは不十分です。 それではSASEではどうか？と言うと以下の図のように、拠点間を含め、すべてに境界を設置、つまりゼロトラストモデルを実現していると言えます。 SSEは、SASEの移行期 SSEは多くの場合、SASEの移行期（移行段階、移行途中）である と言えます。 SCSKでは、世界初のSASEプラットフォーム提供ベンダーであるCato Networks社のCatoクラウド（Cato Cloud/Cato SASE Cloud）を、すでに30社以上のお客様の導入/運用をご支援させていただいておりますが、公開しているお客様導入事例にもありますが、SASE、Catoクラウドの導入にあたっては、いきなりWANの全面移行される例は殆どありません。 多くのお客様においては、リモートアクセスまたはProxyのリプレースでの採用からスタートし、その後、WAN移行（拠点移行）を実施される場合が殆どです。 つまり、PoCも含めると以下のようなプロセスとなります。 1. PoC→リモートアクセス移行→WAN移行→インターネット移行 2. PoC→インターネット移行→リモートアクセス移行→WAN移行 SSEのデータセンターを拠点接続（既存WANとSASE）のハブ拠点として、WANに接続されている拠点を徐々に移行することで、最終的にSASEへ移行することが可能となります。 シングルベンダーSASEについて SCSKでは、2021年から主要なSASEソリューションを一同に紹介を行うオンラインセミナー「SCSK SASE Solution Summit（通称 S4）」を定期的に開催しています。 2021年の開始当初から、Catoクラウド、Prisma Access、Netskope、Zscalerの4ソリューションの引き合いが多かったことから、これらの紹介を行っておりましたが、2022年にガートナーが、SASEの過剰なマーケティングを嫌厭した結果があってか、SASEは1社から購入すべきという方針のもと シングルベンダーSASE（Single-Vendor SASE） つまり単一の1社でSASEを提供するベンダーを再定義しました。 （SASEは、様々なベンダーのソリューションを組み合わせて初めて実現できるものである、と言う誤ったマーケティングも未だに存在しますが） シングルベンダーSASEに選出され、また、2023年8月に発表された「 シングルベンダーSASE マジック・クアドラント（Magic Quadrant for Single-Vendor SASE） 」に選出されたのは、以下の8社となります。 Cato Networks（Cato Cloud/Cato SASE Cloud） Palo Alto Networks（Prisma Access） Versa Networks（Versa SASE） Fortinet（FortiSASE） Cisco Forcepoint（Forcepoint ONE） VMware（VMware SASE） Juniper Networks Zscalerについては、シングルベンダーSASEでは無いため、SASEセミナーであるS4での取り扱いは辞めざるを得なくなりました。 ※Zscalerは、SSEとして定義されています。 あくまでも私見になりますが、ガートナーが、2019年にSASEを提唱し、その後、2021年にSSE、2022年にシングルベンダーSASEを発表したのは、SASEの発表をした後、ありとあらゆるベンダーが、我こそはSASEとしてマーケティングをスタートしましたが、実際には、殆どのソリューションがSASEの定義に沿っておらず、他のパートナーと協業した パートナーシップモデル のサービスが殆どでした。 そのため、2年後にSASEのサブセット（一部分）としてSSEを改めて定義し、その直後に「 SSE マジック・クアドラント(Magic Quadrant for Security Service Edge） 」を発表し、明確にSSEソリューションを定義しました（ちなみに、SSE MQには、Cato Networks社は入っていません） その後も、パートナーシップモデルのSASEが横行したので、シングルベンダーSASEを定義したのではないかと推測しています。 「2023年度版 ゼロトラストネットワーキングのハイプサイクル（Hype Cycle for Zero Trust Networking, 2023）」においても、SASEは多くのテクノロジーベンダーによる誇張されたマーケティングにより幻滅の谷にあるとあります。 2023年には「 シングルベンダーSASE マジック・クアドラント（Magic Quadrant for Single-Vendor SASE） 」も発表されていますので、SSEのみのベンダー、あるいはSASE（シングルベンダーSASE）ベンダーについては、2つのマジック・クアドラントをご覧いただければ良いと思います。 まとめ SSEとSASEについて説明しました。 SSEは、ゼロトラストを目指す場合には、SASEの移行期であると考えています。 もちろんすべての企業がSASEに移行するとは考えていませんが、実際にSSEソリューションからSASE、Catoクラウドへの切り替えのご相談も多く、実際に切り替えをされた事例も少なからずあります。 SSEからSASEへのニーズは、コスト（SSEが契約更新都度に価格アップ）、または通信キャリアのSD-WAN課題（コスト・納期・利便性）となります。 現状のWAN・SD-WANには特に課題はなく、SSE導入のみを検討されているお客様においても、将来的にゼロトラストを目指されているのであれば、SASE（特にシングルベンダーSASE）を前提に検討されるのが良いのではないかと思います。 前述のS4は、次回は2024年2月に開催する予定です。 シングルベンダーSASEの主要ソリューションであるCatoクラウド、Prisma Access、Netskope、Ciscoの4ソリューションを一同に紹介するセミナーですので、SSE、SASEをご検討の方は、是非ご参加ください。 また、SSEとSASEについて迷われている方、ゼロトラストについて相談されたい方は、お気軽に当社までお問い合わせください。

はじめに こんにちは。SCSKのふくちーぬです。 今回は、Amazon API Gateway REST API を自動デプロイするためのちょっとした工夫についてお話しします。 REST APIの場合、2回目のAPIのデプロイ以降、APIの内容に変更があった際に手動で再デプロイする必要があります。 API を更新するたびに、API を既存のステージまたは新しいステージに再デプロイする必要があります。API の更新には、ルート、メソッド、統合、オーソライザー、ステージ設定以外の変更が含まれます。 Amazon API Gateway での REST API のデプロイ - Amazon API Gateway Amazon API Gateway で REST API をデプロイする方法について説明します。 docs.aws.amazon.com   弊社広野の記事にも、その旨が説明されています。 Amazon API Gateway は設定を変更した後に必ずデプロイをする必要があります。そうしないと変更が反映されません。 HTTP API であれば自動デプロイの設定があり、設定変更後に自動でデプロイしてくれます。特別な事情がなければ、安全のために自動デプロイを活用した方が良いと思います。 REST API には自動デプロイの設定がありません。無理やり自動デプロイさせる仕組みも作り込みできなくはないのですが大変です。ここは今後の改善が待たれるところです。 Amazon API Gateway と AWS Lambda の連携でもうハマりたくない [AWS CloudFormation テンプレート付き] Amazon API Gateway と AWS Lambda の連携がうまくできず時間を浪費してしまう方は結構いらっしゃるのではないかと思います。Amazon API Gateway のタイプや AWS Lambda との統合の仕方によって AWS Lambda 関数のコードも変わるので厄介です。私はそこでハマるのが嫌で、Amazon API Gateway と AWS Lambda 関数の標準設定パターンを決めて使い回ししています。 blog.usize-tech.com 2022.04.11   では、この忘れがちな手動での再デプロイの手間をなくすためのを方法を紹介します。 構成とシナリオの確認 構成図 今回作成する構成は、以下の通りです。 一般的な Amazon API Gateway + AWS Lambda の構成ですね。APIに対して、2つのGETメソッドが存在します。 1つ目のGETメソッドを叩くと、UTC（イギリス時間）にて現在時刻が返却されます。 2つ目のGETメソッドを叩くと、JST（日本時間）にて現在時刻が返却されます。 シナリオ シナリオは、以下の通りです。 UTCを取得できるAPIを開発するよう依頼されました。しかし仕様変更が発生してJSTでも取得できるよう依頼され、即座にAPIの更新・デプロイをする必要がでてきました。 これを AWS CloudFormation (以降、CFN) テンプレートで表現していきます。 ①まずは、UTCを取得するためのメソッドを備えたAPIを作成します。 ②UTCが取得できることを確認します。 ③CFNテンプレートを加筆修正して、JSTを取得するためのメソッドも備えたAPIへ自動デプロイ(更新)します。 ④UTC・JSTが取得できることを確認します。 環境準備編（UTC APIの構築） REST APIやLambdaを準備するために、以下のCFNテンプレートにて構築します。 CloudFormationコンソールやCLIにてデプロイをします。 AWSTemplateFormatVersion: '2010-09-09' Parameters: ResourceName:   Type: String APIStage:   Type: String Resources: # ------------------------------------------------------------# #  IAM Role # ------------------------------------------------------------# LambdaRole:   Type: AWS::IAM::Role   Properties:     RoleName: !Sub ${ResourceName}-lambda-role     AssumeRolePolicyDocument:       Version: '2012-10-17'       Statement:         - Effect: Allow           Action: sts:AssumeRole           Principal:             Service:               - lambda.amazonaws.com     ManagedPolicyArns:       - arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole # ------------------------------------------------------------# # APIGateway UtcnowLambda # ------------------------------------------------------------# UtcnowFunction:   Type: AWS::Lambda::Function   Properties:     FunctionName: !Sub ${ResourceName}-lambda-function-utcnow     Role: !GetAtt LambdaRole.Arn     Runtime: python3.11     Handler: index.lambda_handler     Code:       ZipFile: !Sub |         import json         from datetime import datetime, timedelta         def lambda_handler(event, context):             utc_now = datetime.utcnow()             format_time = utc_now.strftime("%Y-%m-%d %H:%M:%S")             print(utc_now)             return {                 'statusCode': 200,                 'body': json.dumps(format_time)             } RestApi:   Type: AWS::ApiGateway::RestApi   Properties:     Name: !Sub ${ResourceName}-apigateway UtcnowResource:   Type: AWS::ApiGateway::Resource   Properties:     RestApiId: !Ref RestApi     ParentId: !GetAtt RestApi.RootResourceId     PathPart: utcnow UtcnowLambdaPermission:   Type: AWS::Lambda::Permission   Properties:     FunctionName: !Ref UtcnowFunction     Action: lambda:InvokeFunction     Principal: apigateway.amazonaws.com   DependsOn: UtcnowResource UtcnowMethod:   Type: AWS::ApiGateway::Method   Properties:     RestApiId: !Ref RestApi     ResourceId: !Ref UtcnowResource     AuthorizationType: None     HttpMethod: GET     Integration:       Type: AWS_PROXY       IntegrationHttpMethod: POST       Uri: !Sub arn:aws:apigateway:${AWS::Region}:lambda:path/2015-03-31/functions/arn:aws:lambda:${AWS::Region}:${AWS::AccountId}:function:${ResourceName}-lambda-function-utcnow/invocations   DependsOn: UtcnowLambdaPermission DeploymentVer1: ##(必須)デプロイメントIDを変更するため、バージョンが分かるよう記載しておく。   Type: AWS::ApiGateway::Deployment   Properties:     RestApiId: !Ref RestApi     Description: ver1 ##(任意)Descriptionを変更するため、バージョンが分かるよう記載しておく。   DependsOn:     - UtcnowMethod     #- JstnowMethod Stage:   Type: AWS::ApiGateway::Stage   Properties:     StageName: !Ref APIStage     Description: dev stage     RestApiId: !Ref RestApi     DeploymentId: !Ref DeploymentVer1 ##(必須)デプロイメントIDを変更するため、バージョンが分かるよう記載しておく。 #------------------------------------------------------------# # APIGateway JstnowLambda #------------------------------------------------------------# # JstnowFunction: #   Type: AWS::Lambda::Function #   Properties: #     FunctionName: !Sub ${ResourceName}-lambda-function-jstnow #     Role: !GetAtt LambdaRole.Arn #     Runtime: python3.11 #     Handler: index.lambda_handler #     Code: #       ZipFile: !Sub | #         import json #         from datetime import datetime, timedelta           #         def lambda_handler(event, context): #             utc_now = datetime.utcnow() #             jst_now = utc_now + timedelta(hours=9) #             format_time = jst_now.strftime("%Y-%m-%d %H:%M:%S")               #             print(jst_now) #             return { #                 'statusCode': 200, #                 'body': json.dumps(format_time) #             }             # JstnowResource: #   Type: AWS::ApiGateway::Resource #   Properties: #     RestApiId: !Ref RestApi #     ParentId: !GetAtt RestApi.RootResourceId #     PathPart: jstnow #   DependsOn: #     - RestApi # JstnowLambdaPermission: #   Type: AWS::Lambda::Permission #   Properties: #     FunctionName: !Ref JstnowFunction #     Action: lambda:InvokeFunction #     Principal: apigateway.amazonaws.com #   DependsOn: JstnowResource # JstnowMethod: #   Type: AWS::ApiGateway::Method #   Properties: #     RestApiId: !Ref RestApi #     ResourceId: !Ref JstnowResource #     AuthorizationType: None #     HttpMethod: GET #     Integration: #       Type: AWS_PROXY #       IntegrationHttpMethod: POST #       Uri: !Sub arn:aws:apigateway:${AWS::Region}:lambda:path/2015-03-31/functions/arn:aws:lambda:${AWS::Region}:${AWS::AccountId}:function:${ResourceName}-lambda-function-jstnow/invocations   #   DependsOn: JstnowLambdaPermission デプロイ後のURLを叩きます。 今回の場合は、”https://lefldh5ct1.execute-api.ap-northeast-1.amazonaws.com/dev/utcnow”となります。 restapiidは、各々異なるため自身のものをご確認ください。 現在時刻のUTCが取得できましたね！ API更新編（JST APIの追加） 上記テンプレートを修正して、現在時刻がJSTでも取得でき、自動デプロイされるようにします。 CFNテンプレートの記述テクニック Deploymentの論理IDを強制的に変更することで、デプロイメントが再作成されるようにする。 これだけで、自動デプロイが可能になります。加筆・修正箇所をそれぞれ見ていきましょう。 JST APIの追加 1番簡単な箇所から説明します。UTC APIの時と同様に、JSTにて現在時刻が取得できるようリソースを追加します。 コメントアウトを外すだけです。 #------------------------------------------------------------# # APIGateway JstnowLambda #------------------------------------------------------------# JstnowFunction:   Type: AWS::Lambda::Function   Properties:     FunctionName: !Sub ${ResourceName}-lambda-function-jstnow     Role: !GetAtt LambdaRole.Arn     Runtime: python3.11     Handler: index.lambda_handler     Code:       ZipFile: !Sub |         import json         from datetime import datetime, timedelta                 def lambda_handler(event, context):             utc_now = datetime.utcnow()             jst_now = utc_now + timedelta(hours=9)             format_time = jst_now.strftime("%Y-%m-%d %H:%M:%S")                         print(jst_now)             return {                 'statusCode': 200,                 'body': json.dumps(format_time)             }             JstnowResource:   Type: AWS::ApiGateway::Resource   Properties:     RestApiId: !Ref RestApi     ParentId: !GetAtt RestApi.RootResourceId     PathPart: jstnow   DependsOn:     - RestApi JstnowLambdaPermission:   Type: AWS::Lambda::Permission   Properties:     FunctionName: !Ref JstnowFunction     Action: lambda:InvokeFunction     Principal: apigateway.amazonaws.com   DependsOn: JstnowResource JstnowMethod:   Type: AWS::ApiGateway::Method   Properties:     RestApiId: !Ref RestApi     ResourceId: !Ref JstnowResource     AuthorizationType: None     HttpMethod: GET     Integration:       Type: AWS_PROXY       IntegrationHttpMethod: POST       Uri: !Sub arn:aws:apigateway:${AWS::Region}:lambda:path/2015-03-31/functions/arn:aws:lambda:${AWS::Region}:${AWS::AccountId}:function:${ResourceName}-lambda-function-jstnow/invocations   DependsOn: JstnowLambdaPermission デプロイメントの修正 デプロイメントの記述部分を修正します。 デプロイメントのリソースIDについて、”DeploymentVer1″から”DeploymentVer2″に修正してください。これにより、devステージへ自動で再デプロイされるようにします。 “Description”についても、後々分かりやすいように”ver2″と修正しておきましょう。 最後に”DependsOnについて、”JstnowMethod”を追加しましょう。JST APIのリソース・メソッドが作成された後に、デプロイされるようコントロールしています。 DeploymentVer2: ##(必須) DeploymentVer2に変更。   Type: AWS::ApiGateway::Deployment   Properties:     RestApiId: !Ref RestApi     Description: ver2 ##(任意)ver2に変更。   DependsOn:     - UtcnowMethod   - Jst nowMethod   完成したテンプレート 完成した加筆修正後のテンプレートは、以下の通りです。 AWSTemplateFormatVersion: '2010-09-09' Parameters: ResourceName:   Type: String APIStage:   Type: String Resources: # ------------------------------------------------------------# #  IAM Role # ------------------------------------------------------------# LambdaRole:   Type: AWS::IAM::Role   Properties:     RoleName: !Sub ${ResourceName}-lambda-role     AssumeRolePolicyDocument:       Version: '2012-10-17'       Statement:         - Effect: Allow           Action: sts:AssumeRole           Principal:             Service:               - lambda.amazonaws.com     ManagedPolicyArns:       - arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole # ------------------------------------------------------------# # APIGateway UtcnowLambda # ------------------------------------------------------------# UtcnowFunction:   Type: AWS::Lambda::Function   Properties:     FunctionName: !Sub ${ResourceName}-lambda-function-utcnow     Role: !GetAtt LambdaRole.Arn     Runtime: python3.11     Handler: index.lambda_handler     Code:       ZipFile: !Sub |         import json         from datetime import datetime, timedelta         def lambda_handler(event, context):             utc_now = datetime.utcnow()             format_time = utc_now.strftime("%Y-%m-%d %H:%M:%S")             print(utc_now)             return {                 'statusCode': 200,                 'body': json.dumps(format_time)             } RestApi:   Type: AWS::ApiGateway::RestApi   Properties:     Name: !Sub ${ResourceName}-apigateway UtcnowResource:   Type: AWS::ApiGateway::Resource   Properties:     RestApiId: !Ref RestApi     ParentId: !GetAtt RestApi.RootResourceId     PathPart: utcnow UtcnowLambdaPermission:   Type: AWS::Lambda::Permission   Properties:     FunctionName: !Ref UtcnowFunction     Action: lambda:InvokeFunction     Principal: apigateway.amazonaws.com   DependsOn: UtcnowResource UtcnowMethod:   Type: AWS::ApiGateway::Method   Properties:     RestApiId: !Ref RestApi     ResourceId: !Ref UtcnowResource     AuthorizationType: None     HttpMethod: GET     Integration:       Type: AWS_PROXY       IntegrationHttpMethod: POST       Uri: !Sub arn:aws:apigateway:${AWS::Region}:lambda:path/2015-03-31/functions/arn:aws:lambda:${AWS::Region}:${AWS::AccountId}:function:${ResourceName}-lambda-function-utcnow/invocations   DependsOn: UtcnowLambdaPermission DeploymentVer2: ##(必須) DeploymentVer2に変更。   Type: AWS::ApiGateway::Deployment   Properties:     RestApiId: !Ref RestApi     Description: ver2 ##(任意)ver2に変更。   DependsOn:     - UtcnowMethod       - Jst nowMethod       Stage:   Type: AWS::ApiGateway::Stage   Properties:     StageName: !Ref APIStage     Description: dev stage     RestApiId: !Ref RestApi     DeploymentId: !Ref DeploymentVer2 ## (必須) DeploymentVer2に変更 #------------------------------------------------------------# # APIGateway JstnowLambda #------------------------------------------------------------# JstnowFunction:   Type: AWS::Lambda::Function   Properties:     FunctionName: !Sub ${ResourceName}-lambda-function-jstnow     Role: !GetAtt LambdaRole.Arn     Runtime: python3.11     Handler: index.lambda_handler     Code:       ZipFile: !Sub |         import json         from datetime import datetime, timedelta                 def lambda_handler(event, context):             utc_now = datetime.utcnow()             jst_now = utc_now + timedelta(hours=9)             format_time = jst_now.strftime("%Y-%m-%d %H:%M:%S")                         print(jst_now)             return {                 'statusCode': 200,                 'body': json.dumps(format_time)             }             JstnowResource:   Type: AWS::ApiGateway::Resource   Properties:     RestApiId: !Ref RestApi     ParentId: !GetAtt RestApi.RootResourceId     PathPart: jstnow   DependsOn:     - RestApi JstnowLambdaPermission:   Type: AWS::Lambda::Permission   Properties:     FunctionName: !Ref JstnowFunction     Action: lambda:InvokeFunction     Principal: apigateway.amazonaws.com   DependsOn: JstnowResource JstnowMethod:   Type: AWS::ApiGateway::Method   Properties:     RestApiId: !Ref RestApi     ResourceId: !Ref JstnowResource     AuthorizationType: None     HttpMethod: GET     Integration:       Type: AWS_PROXY       IntegrationHttpMethod: POST       Uri: !Sub arn:aws:apigateway:${AWS::Region}:lambda:path/2015-03-31/functions/arn:aws:lambda:${AWS::Region}:${AWS::AccountId}:function:${ResourceName}-lambda-function-jstnow/invocations   DependsOn: JstnowLambdaPermission スタックの更新 上記テンプレートを使用して、スタックの更新を行ってください。 スタックの更新が完了したら、リソースの作成順序を確認してみましょう。 JST Resource作成 ⇒ JST Lambda作成 ⇒ JST Method作成 ⇒ Deployment Ver2作成 ⇒ Dev Stage更新 ⇒ Deployment Ver1削除 つまりデプロイメントが再作成されていることを示しています。 マネジメントコンソールから手動で再デプロイせずに、自動デプロイが完了しました！ API呼び出し では、早速APIリクエストをしてみましょう。 UTC APIリクエスト 先ほどど同様のリクエストURLとなります。   JST APIリクエスト 今回の場合は、”https://lefldh5ct1.execute-api.ap-northeast-1.amazonaws.com/dev/utcnow”となります。 リソース部分が異なるだけですね、JSTでのAPIリクエストも成功しました！ あれ、日本時間の深夜1時にリクエストしていますね。。いえいえただの夜更かしです（笑） 注意点 自動デプロイ実施時は、ステージに関連付いているデプロイ履歴が1つしか保有できません。 つまり、以下のような状態になります。 ステージのデプロイ履歴から、以前のバージョン(ver1)に戻すことができないのでご注意ください。この事象は、デプロイメントを再作成しているのが起因です。もし以前のバージョンに戻す際は、以前のCFNテンプレートを利用しデプロイメントを再作成する流れとなります。 自動デプロイを利用する際には、CFNテンプレートを別途Gitでバージョン管理・保管しておくこと まとめ いかがだったでしょうか。REST APIを自動デプロイするためのテクニックをご紹介しました。メリット・デメリットも感じましたが、要件に応じて導入も検討して頂ければと思います。そしてREST APIの自動デプロイがサポートされることを心待ちにしています。 本記事が皆様のお役にたてば幸いです。 ではサウナラ～🔥

はじめに こんにちは。SCSKのふくちーぬです。 今回は、Cloud9を削除してしまった際の適切な復元方法についてお話します。 この話をしようと思ったきっかけとして、利用しているCloud9の実体であるEC2が削除されてしまい、「一体どうすればいいんだ！」と思った経験が背景となります。 というのも、弊社検証環境ではEC2(=Cloud9)が一定期間起動していないものについてはAMI化し、EC2を削除する仕組みが稼働しております。この仕組みのおかげで、コスト削減が実現できております。実際には他の仕組みも動いているのですが、その話はまた今度することにします。 それでは、EC2を削除してしまった際の対処方法を紹介します。 Cloud9環境準備編 今回の状況を再現するために、Cloud9環境を準備します。 Cloud9を構築する Cloud9の構築手順について分かる方は、飛ばしていただいて結構です。 ご自身のアカウントにて、VPC及びサブネット、IGW、ルートテーブル等が構築済みであることが前提となります。 以下の手順を参考に、Cloud9を構築します。 ステップ 1: 環境を作成する - AWS Cloud9 (「 」の最初のステップ) docs.aws.amazon.com コンソール画面から、”Cloud9″を入力し選択します。 “環境を作成”を押下します。 名前は、任意のもので大丈夫です。ここでは、”cloud9-20231121″と入力しています。 インスタンスタイプも何でも良いですが、一番料金が安い最小サイズの”t2.micro”を選択しています。 接続方法として、お手軽に試すことができる”AWS Systems Manager (SSM)”を選択しています。 VPC設定では、任意のVPC,サブネットを指定してください。 ここでは、以下のように設定しています。 VPC：vpc-092d2b38fb260b53b サブネット：subnet-02cb24e380508f54e   設定内容が正しいことを確認後、”作成”を押下してください。 以下のような画面になっていれば、問題なくCloud9の構築ができています。 続いて上記画面にて、”Cloud9で開く”を押下してください。 数分待つとCloud9の環境が立ち上がりました！ Cloud9でファイルの作成をする ここからが本題です。 EC2を削除する前に、Cloud9上で特定のファイルを作成しておき”世界で一つだけのCloud9″にしましょう。 この意図として、復元後に該当ファイルの存在を確かめる作業を実施します。 “New File”を押下してください。 本文には以下のように入力して、ファイル名は”test.txt”とします。 これにてCloud9の準備完了です。 スナップショット取得編 EC2のAMIを取得する Cloud9の実体であるEC2にアクセスします。”EC2インスタンスの管理”を押下してください。 静止点を設けるために、EC2の停止をしておきます。”インスタンスを停止”を押下してください。 AMIを作成するために、”イメージを作成”を押下してください。 イメージ名は、任意のもので大丈夫です。ここでは、”ami-cloud9-20231121″と入力しています。 “イメージを作成”を押下します。 数分後に、AMIが作成されていることを確認しましょう。 EC2削除編 EC2を削除する では実際にEC2(=Cloud9)が一定期間起動していないものを削除する仕組みが動いていたと仮定して、EC2を削除してみましょう。 “インスタンスを終了”を押下してください。 “終了”を押下してください。 先ほどまで、ステークスが”準備完了”であったCloud9ですが、”エラー”になっていることが分かります。 “Cloud9で開く”を押下して、利用できないことを確認してください。 “Return to dashboard”を押下して、コンソールに帰ってきてください。 Cloud9の実体であるEC2が削除されてしまったため、Cloud9が利用できなくなっていますね。 復元編 Cloud9の実体となるEC2を削除してしまった場合は、新規にCloud9を作成し、ボリュームの入れ替えをすることが必須となります。　　（※該当のCloud9環境は、何も利用できず抜け殻のような状態となります。） 復元の手順は、以下の通りです。 新しいCloud9を作成する ボリュームの入れ替えをする 復元の確認する 新しいCloud9を作成する 同様の手順で新しく別のCloud9を作成してください。 ここでは、名前を”cloud9-ver2-20231121″としています。 実際にCloud9を起動してみると、もちろん”test.txt”ファイルの存在しない初期状態のCloud9となります。 ボリュームの入れ替えをする 以下を参考に、新しいCloud9のルートボリュームに対して入れ替えを行っていきます。 Cloud9を停止することなく入れ替えを実施することが可能です。 以前のスナップショットを使用したボリュームの置き換え - Amazon Elastic Compute Cloud Amazon EBS ボリュームを Amazon S3 に保存した以前のスナップショットのデータに置き換えます。 docs.aws.amazon.com   “cloud9-ver2-20231121″のEC2を選択して、”ルートボリュームを置き換える”を押下してください。 各自取得したAMIのイメージIDを選択してください。元のボリュームは必要ないので、チェックも入れておきます。 “置き換えタスクを作成”を押下します。 ルートボリュームの入れ替えに成功し、復元したいボリュームがアタッチされました。 復元後の確認 実際にCloud9を起動して、中身を確認していきましょう。 “test.txt”ファイルが存在することを確認できました。 後片付け Cloud9の削除 古いCloud9は利用できないため、削除しておきましょう。 AMIとスナップショットの削除 AMIとスナップショットも料金がかかるので、削除しておきましょう。 まとめ いかがだったでしょうか。これでEC2が削除されても、AMI・スナップショットを取得しておけば安心してCloud9を復元できます。 本記事が皆様のお役にたてば幸いです。 ではサウナラ～🔥

こんにちは。SCSKの島村です。 Google Cloud のカンファレンスイベント Google Cloud Next Tokyo’23 が国内4年ぶりに 東京ビックサイト にて開催されました。 11月15日（水）－16日（木） の二日間にわたり基調講演や、先進事例セッション、テーマ別のブレイクアウトセッションなど、 充実のプログラムがご用意されておりました。また、 この度当社は、Platinumスポンサーとしても出展させていただきました。 2日間の開催期間中、多くのお客様にご来場いただきました。ありがとうございました。 本記事では、2日間に及んだGoogle Cloud Next Tokyo’23について当社の出展内容を少しだけご紹介させていただければと思います。 弊社では、Google CloudのAI/MLの技術を生かしたソリューションを提供しております。今回の展示会では、その技術を実際に現地でご体験いただけるような2つのデモを実施いたしました。 実施したデモについて、本ブログでも内容を共有させていただきます！！！！ スポンサーブース＠Expoについて Google Cloud パートナーによるスポンサー展示ブースでは、各社がGoogle Cloud（GCP）やGoogle Workspace のデモや導入事例について取り組みをご紹介するだけでなく、導入支援に関するご相談やクラウド全般に関するご質問をオンサイトで行える、そんなスペースです。 SCSKブースでは、弊社のGoogle Cloud に関するこれまでの取り組みをデモを交えながらご紹介させていただきました。 弊社オリジナルキャラクターの「かつのすけ」君です。　Googleカラーの腹巻がとてもお似合いですね。   SCSKブースデモ① コンタクトセンター向け生成AIチャットボットのご紹介 コンタクトセンタ-向けの生成AIチャットボットデモについてご紹介します。 今回は、弊社プレスリリースでも紹介させていただいている「生成AIチャットボット」をブースにてご来場いただいたお客様にお試しいただきました。 プレスリリースの詳細はこちら☟☟☟ 是非こちらもご一読下さい。 すぐに試せる！効果が分かる！「その問い合わせ、もうシナリオを作らなくても生成AIがお答えします」チャットボット・ボイスボットへのビルトイン・生成AIサービスを提供開始 (scsk.jp) Vertex AI Search とは？ Vertex AI Search は、生成AIを活用した検索エンジンを構築するためのサービスです。生成AIによる結果のサマライズやパーソナライズなどの検索結果の強化に加えデータをアップロードするだけで簡単に構築と管理が可能となります。 Vertex AI Search and Conversation の一般提供を開始 | Google Cloud 公式ブログ cloud.google.com より詳しい内容については過去の記事をご確認いただけますと幸いです。 Vertex AI Search and Conversationが一般提供されたので触ってみました【Search編】 SCSK青木です。今回はGoogle CLoud Next'23で一般提供されたVertex AI Search and ConversationのSearchを触ってみました。 blog.usize-tech.com 2023.09.05 Vertex AI Search and Conversationが一般提供されたので触ってみました【Conversation編】 SCSK青木です。Google Cloud Next’23にて一般提供されたVertex AI Search and Conversationを触ってみました。今回はConversationに関して記載しています。 blog.usize-tech.com 2023.09.05 デモ詳細 架空企業のコンタクトセンターを想定した、Vertial Agentによるお客様とのやり取りをデモにてご紹介させていただきました。 Google CloudのPaLM2やOpen AIのGPT-3.5/4などの基盤モデル（FM）では回答が難しかった（ ハルシネーションを起こしていた ）質問に対しても、  企業独自のデータへグラウンディング （接地）し、より 回答率/回答精度の高い ナレッジベースの 生成AIチャットボット をGoogle Cloudのサービスを利用して構築いたしました。 すぐに試せる！効果が分かる！「その問い合わせ、もうシナリオを作らなくても生成AIがお答えします」チャットボット・ボイスボットへのビルトイン・生成AIサービスを提供開始 (scsk.jp) サービスの特徴 チャットボットやボイスボットにおいて、 ① 利用開始時に必要不可欠でありながら煩雑で作業負荷の高い「回答シナリオの作成・メンテナンス」が不要で、 ②  自社で有するナレッジベースやドキュメントを読み込ませることで生成 AIが回答を生成します。  　 また、「この質問には必ず同じ回答を返す」という個別のルール設定も可能です。 実際のデモ画面①☟☟☟☟ お客様とのやり取りを記録し、生成系でサマライズ！！！！（画面右側） 要件や解決の有無だけでなく、お客様の感情も分析しオペレータへのアドバイスがあることでデータを収集するだけでなく、効率的な活用まで！！！   実際のデモ画面②☟☟☟☟ お客様とのやり取りをダッシュボードで可視化！！！！ 問い合わせの件数や、実際の問い合わせに対して生成AIの回答精度など等、様々な情報をダッシュボードにて簡単に確認可能。   SCSKブースデモ② 製造業向け外観検査ソリューションのご紹介 製造業向け外観検査ソリューションデモについてご紹介します。 今回は、Google Cloud の外観検査ソリューションである「Visual inspection AI」の本番導入時をイメージできるような、ミニチュアサイズのデモをご用意いたしました。 実際にカメラとPCを接続し、その場で対象物を撮像し本番ラインを想定した外観検査のデモを実施いたしました。 Visual inspection AI とは？ 製造業の外観検査に特化したGoogle CloudのAIサービスであり、  ● 特徴として「プログラム開発を必要とせず、GUI操作のみですぐに利用可能」 なサービスとなっております。 さらに「目的に応じて3つのモデルを選択」することが可能です。 より詳しい内容については過去の記事をご確認いただけますと幸いです。 【GCP】Visual Inspection AIの新モデル Anomaly Detection を触ってみた！！ Google Cloudの外観検査特化サービス「Visual Inspection AI」について、新モデルが追加されたことをご存じでしょうか？ 今回は、Visual Inspection AIの新モデルであるAnomaly Detectionを実際に使用してみましたのでご紹介させていただきます。 blog.usize-tech.com 2023.04.28 デモ詳細 今回は「スマートフォンの表面の細かな傷を検証する」モデルをご用意させていただきました。  ① 産業用カメラ（写真左）でその場で傷のついたスマートフォンを撮影  ② Visual inspection AIで作成したモデルを利用して推論を実施  ③ その場で推論結果を表示する 実際の向上のラインを想定したEdgeソリューションとしてのデモを見ていただきました。 当日デモの準備時間の写真を少しだけ☟☟ 今回作成した外観検査モデルですが、モデルの学習に利用したデータは、数十枚の正常データ（傷のないアイフォーンの画像）と異常（表面に傷のついた画像）データのみです。 少ない枚数ですが、そこそこの精度を出すことができております。業界固有のドメインに特化したVisual inspection AIならではの強みを体感いただけたのではないでしょうか。   最後に 今回は Google Cloud Next Toyko’23における当社の取り組み についてご紹介させていただきました。 多くのお客様にご来場いただき、弊社の取り組みについてお話をさせていただけたこ大変感謝いたします。皆様のご来場とご意見を励みに、今後もより一層の技術力向上に努めてまいります。 また、今回ご紹介した「生成AIチャットボット」「製造業向け外観検査ソリューション」についてもっと知りたい方は、個別のご相談も承っております。 ありがたいことに、当日多くの方に足を運んでいいだきその場でお話できなかったことやご相談などお気軽にお声掛けください。 お問い合わせは以下のフォームからお願い致します。 お問い合わせ製品・サービス名に「Google Cloud」を選択してください。 お問い合わせ｜クラウド移行だけでは描けない、理想のDXを実現する www.scsk.jp 今後とも、AIMLに関する情報やGoogle CloudのAIMLサービスのアップデート情報を掲載していきたいと思います。 最後まで読んでいただき、ありがとうございました！！！

前回は、サーバレスコンピューティングとは何か、そしてセキュリティの課題と対策の重要性について簡単に解説しました。   サーバレスセキュリティについて考える ① サーバーレスアーキテクチャの理解とそのセキュリティ課題の詳細な洞察を提供します。サーバーレス環境でのセキュリティ対策の重要性とその理由も解説します。技術者、デベロッパー、ITマネージャー必見の内容です。 blog.usize-tech.com 2023.07.21   今回は具体的に、どのようなセキュリティ対策が必要かについて、基本的な考え方を紹介します。   本題に入る前にお知らせです！ ＝＝＝＝＝＝＝ 【CSPMマネージドサービス SmartOneCloudSecurity】 SmartOneCloudSecurityは、PrismaCloudを用いたCSPMマネージドサービスです。PrismaCloudの導入から設定変更まで、弊社技術担当者がお客様のCSPM対策をサポートします。CSPMの導入を検討中の方はもちろん、PrismaCloudを利用中だけど機能や運用面でもっと上手に活用したい、というような課題をお持ちな方は、お気軽に下記URLからお問い合わせください。PrismaCloudのPoCの相談も受けています。 New!!   2023/4より、CWPPの導入サポートも始めました！   Smart One Cloud Security® パブリッククラウドのセキュリティ設定を診断/監視するマネージドCSPMサービスです。Palo Alto Networks社Prisma Cloud（CSPM機能）を使い易く、簡単に導入いただけます。 www.scsk.jp   １．何に対して対策をしないといけないか セキュリティ対策を考える前に、どの領域が対象なのかを明確にする必要があります。 Lambdaの責任共有モデル AWSが提供するLambdaの責任共有モデルを例にとって、サーバレス環境におけるユーザーのセキュリティ責任を探ります。このモデルによると、関数のコード、使用するライブラリ、関数の設定、Identity and Access Management（IAM）のセキュリティ対策がユーザーに求められます。また、AWSのドキュメントには記載されていませんが、データ保護と監視も重要です。つまり、データの暗号化やアプリケーションの性能監視といった対策も必要です。加えて、セキュリティという観点からは、実際にアプリケーションが稼働するワークロードの防御も考慮に入れなければなりません。 ※出典： 責任共有モデル ２．何を対策しないといけないか 次に、何を対策しないといけないかを考えます。サーバレスセキュリティ対策においては、AWSを例に取り、具体的な対策を整理するために次の２つのフレームワークが参考になります。 AWS Well-Architected Framework Serverless Applications Lens CIS Benchmark AWS Well-Architected Framework Serverless Applications Lens AWS Well-Architected Framework Serverless Applications Lens は、セキュリティ、信頼性、パフォーマンス効率、コスト最適化の４つの主要な柱に基づいて、サーバレス特有のベストプラクティスを提供するガイドラインです。セキュリティの柱においては、以下のような対策を行うことが推奨されています。 アイデンティティとアクセス管理 最小特権の原則は、サーバレスセキュリティの土台になります。IAMを用いて関数、データベース、その他リソースへのアクセスを細かく制御します。 インフラストラクチャの保護  サーバレスアーキテクチャでは、アプリケーションが複数のサービスにまたがって稼働します。そのため、ネットワークのセグメンテーションが重要であり、LambdaのセキュリティグループやVPCの適切な設定によりアクセスを制限します。 データの保護 サーバレスアプリケーションはデータが頻繁に移動するため、データは保管状態または転送中であっても暗号化が必須です。KMSを利用してキー管理を行うことで、データを安全に保持します。 検出制御 セキュリティ侵害を迅速に特定するためには、異常なアクティビティを検出する仕組みが必要です。CloudWatch、CloudTrail、またはサードパーティ製のツールを使用して監視を行います。 ※現状、異常なアクティビティを防御しようとすると、サードパーティ製の製品を導入が必要 インシデントレスポンス  セキュリティインシデントが発生した場合の迅速な対応は不可欠です。事前にインシデント対応計画を策定し、自動化された応答メカニズムを導入しておくべきです。 ※参考： Security pillar さらに、AWS Well-Architected Framework Serverless Applications Lensでは、サーバレスを構成する以下の８つのレイヤーについて記載があります。 コンピュートレイヤー データレイヤー メッセージング・ストリーミングレイヤー ユーザー管理とアイデンティティレイヤー エッジレイヤー システムの監視とデプロイレイヤー デプロイアプローチ Lambdaのバージョン管理 これらのレイヤーは、上記の柱と連動しており、AWSサービスを用いて適切なセキュリティ対策を実施できるように設計されています。 アイデンティティとアクセス管理 ⇔ ユーザー管理とアイデンティティレイヤー インフラストラクチャの保護 ⇔ コンピュートレイヤー、データレイヤー、メッセージング・ストリーミングレイヤー、エッジレイヤー データの保護 ⇔ データレイヤー 検出制御 ⇔ システムの監視とデプロイレイヤー 各レイヤーに代表的なサーバレスサービスをマッピングしてみると以下のようになります。考え方のベースとなる柱に対して適切にサービスが散りばめられていて、こう見るとよくできているサービス構成に思えます。   CIS Benchmark CognitoやIAMを用いた認証・認可の強化や、各サービスに対する最小限の権限付与、LambdaやRDSへのセキュリティ対策、CloudWatchやX-Rayによる監視・分析など、基本的なアプローチが明確になりました。次は、CISベンチマークを参考に、これらのサービスに具体的にどのような設定を適用すべきかを検討します。 CISベンチマークは、Center for Internet Security（CIS）によって策定された業界標準のベストプラクティス集です。他のコンプライアンスガイドラインと比較して、より実務に即した技術的設定に重点を置いており、具体的な手順が明確に示されています。 今回も例としてAWSに焦点を当てます。AWSに関するCISベンチマークのドキュメントには以下の4種類があり、各々からサーバーレスサービスに関する重要な記述を抜粋してみます。 CIS Amazon Web Services Foundations Benchmark v2.0.0 CIS AWS End User Compute Services Benchmark v1.1.0 CIS AWS Compute Services Benchmark v1.0.0 CIS Amazon Web Services Three-tier Web Architecture Benchmark v1.0.0 CIS Amazon Web Services Foundations Benchmark v2.0.0 CIS No 推奨事項 2.1.1 S3 バケットポリシーが HTTP リクエストを拒否するように設定されていることを確認する 2.1.2 S3 バケットで MFA Delete が有効になっていることを確認する 2.1.3 Amazon S3内のすべてのデータが検出され、分類され、必要に応じて保護されていることを確認する。  ※Amazon S3バケットには機密データが含まれている可能性があり、セキュリティ目的のために発見、監視、分類、保護されるべきである。Macieと他のサードパーティツールは、Amazon S3バケットのインベントリを自動的に提供することができる。 2.1.4 S3 バケットが「パブリックアクセスをブロック（バケット設定）」で構成されていることを確認する 2.3.1 RDSインスタンスで静止時の暗号化が有効になっていることを確認する 2.3.2 RDSインスタンスの自動マイナーバージョンアップグレード機能が有効であることを確認する 2.3.2 RDSインスタンスにパブリックアクセスが与えられないようにする 3.6 CloudTrail S3バケットでS3バケットアクセスロギングが有効になっていることを確認する 3.10 書き込みイベントのオブジェクトレベルロギングがS3バケットで有効になっていることを確認する 3.11 S3 バケットで読み取りイベントのオブジェクトレベルロギングが有効になっていることを確認する 4.1 未承認の API 呼び出しを確実に監視する 4.8 S3 バケットポリシーの変更を確実に監視する ※CIS Amazon Web Services Foundations Benchmark v2.0.0 から引用、翻訳   CIS AWS Compute Services Benchmark v1.0.0 CIS No 推奨事項 4.1 AWS ConfigがLambdaで有効になっていることを確認する 4.2 Cloudwatch Lambda insightsが有効になっていることを確認する 4.3 AWS Secrets Managerが設定され、データベース用のLambdaで使用されていることを確認する 4.4 ラムダ関数へのアクセスに最小特権が使用されることを保証する。 4.5 すべてのラムダ関数が独自の IAM ロールを持つようにする 4.6 ラムダ関数が誰にでも公開されないようにする。 4.7 ラムダ関数がアクティブな実行ロールを参照していることを確認する。 4.8 Lambda関数でCode Signingが有効になっていることを確認する。 4.9 AWSアカウント内に管理者権限を持つLambda関数がないことを確認する 4.10 ラムダ関数が、権限ポリシーによって未知のクロスアカウントアクセスを許可しないようにする。 4.11 ラムダ関数に使用する実行環境のバージョンにサポート終了日がないことを確認する。 4.12 Lambda環境変数で転送中の暗号化が有効になっていることを確認する ※CIS AWS Compute Services Benchmark v1.0.0 から引用、翻訳   CIS Amazon Web Services Three-tier Web Architecture Benchmark v1.0.0 CIS No 推奨事項 1.4 RDS 上で実行されるデータベースで、静止時の暗号化が有効になっていることを確認する 1.16 全てのS3バケットで、バケットに格納されている全てのオブジェクトに対してサーバーサイドおよびトランジット暗号化を必須とするポリシーがあるか確認する 3.5 リレーショナルデータベースサービスがマルチAZで有効になっていることを確認する 3.6 リレーショナルデータベースサービスのインスタンスにおいて、自動マイナーバージョンアップグレードが有効であることを確認する 3.8 リレーショナル データベース サービスのバックアップ保持ポリシーが設定されていることを確認する 3.11 S3 バケットのバージョン管理が有効になっていることを確認する 3.12 CloudFront Viewer プロトコルポリシーを使用した HTTP から HTTPS へのリダイレクトが設定されていることを確認する 3.13 すべての CloudFront ディストリビューションで CloudFront と Web 層 ELB オリジンの間で HTTPS が必要であることを確認する 4.1 Cloudtwatch アラームおよび Auto-Scaling グループ (スコア付き) から通知を送信するための SNS トピックが作成されていることを確認する 4.2 RDS イベントから通知を送信するための SNS トピックが作成されていることを確認する 4.3 RDS イベント サブスクリプションがインスタンス レベルのイベントに対して有効になっていることを確認する 4.4 RDS イベント サブスクリプションが DB セキュリティ グループに対して有効になっていることを確認する 5.3 AWS Cloudfront Logging が有効になっていることを確認する 5.5 Cloudwatch ログ グループがアプリ層用に作成されていることを確認する 5.7 アプリ層の Cloudwatch ログ グループに保持期間があることを確認します 6.4 Cloudfront ディストリビューション内で地域制限が有効になっていることを確認する 6.30 RDS データベースがパブリックにアクセスできないことを確認する 6.34 RDS データベースがデータ層セキュリティ グループを使用するように構成されていることを確認する ※CIS Amazon Web Services Three-tier Web Architecture Benchmark v1.0.0 から引用、翻訳 CISベンチマークでは、各サービスの具体的な設定方法が明確に示されており、さらにAWS Secrets ManagerやMacieなどの追加サービスを利用したセキュリティ対策も詳細に記述されています。セキュリティ設定に関して不明な点がある場合は、まずはこれらのガイドラインに従って設定を行うことをお勧めします。 ３．対策の全体像 これまでの内容を基に、サーバレスセキュリティにおける対策を、サーバレスシステム構築の構成例に適用する形で整理してみます。 CISベンチマークでは、各サービスの詳細な設定推奨事項が記載されています。ここでそれらを全て取り上げるには量が多すぎますが、基本的には全てのサービスにおいて、各サービス固有のセキュリティベストプラクティスに従った適切な設定が必要です。なお、これらの設定が正しく行われていることを、CSPMソリューションで監視し、設定の不備をリアルタイムに検出することが重要です。 アイデンティティとアクセス管理では、Cognitoを使用して認証・認可を実施し、認証を通過した通信のみを許可します。また、IAMを用いて各サービスに必要最小限の権限を付与し、もし悪意あるユーザーが侵入しても、被害を最小限に抑える体制を整えます。 インフラストラクチャー保護のためには、エッジサービスであるCloudFrontやAPI GatewayにWAFを導入して防御対策を施します。データベースへの認証情報はSecrets Managerで管理し、Lambda関数にはSignerでの署名を用いて、データベースアクセスやLambdaの利用を承認されたユーザーに限定します。さらに、ワークロードとランタイムの保護には、CWPPソリューションを活用して実行環境の脆弱性管理と防御対策を実施します。 データ保護に関しては、保管場所だけでなく伝送中のデータも暗号化します。また、Macieを用いてS3に保存された機密データを特定し、そのアクセスを監視します。 検出制御の観点では、CloudWatchやX-Rayを使用して適切な監視と分析を行える状態にし、異常な状態を定義できればSNSでアラート通知させます。また、前提とした各サービス毎のセキュリティのベスプラに基づく適切な設定が行われていることを監視するために、Security Hubやサードパーティ製CSPMソリューションで脆弱な設定がないことを継続的に監視することも重要です。 ここまでで、サーバレスセキュリティの基本的な対策について考えてみました。サーバレスセキュリティの対策としては、ランタイムやライブラリの脆弱性の管理なども考える必要があるので、次回は更に一歩踏み込んで、脆弱性管理や実際にCWPP製品を使ってみて、どういった対策を行うことができるかを確認していきたいと思います。   CWPPとは何か? クラウドワークロード保護の必要性を解説 クラウド上のデータとアプリケーションの安全性を確保するソリューションとして、日本でも徐々にCWPPの認知度が高まってきています。 CWPPの概要と必要性について解説します。 blog.usize-tech.com 2023.05.23

こんにちは、SCSK株式会社の池田です。 前回は、HAクラスタウェアの「 LifeKeeper（ライフキーパー） 」という製品の概要をご説明しましたが、２回目の今回は少しだけ掘り下げて、LifeKeeperで可用性を高められるミドルウェアにどのようなものがあるかをご紹介します。 HAクラスタウェア「LifeKeeper」で可用性を高めよう！ BCPが求められるシステムの決定版！AWSを代表とするパブリッククラウド上の任意のミドルウェアの可用性を向上できるHAクラスタウェアの「LifeKeeper（ライフキーパー）」について概要をご説明します！ blog.usize-tech.com 2023.11.20   LifeKeeperには、数多くのミドルウェアに対応したオプション製品がある！ LifeKeeperには、サイオステクノロジーやミドルウェアメーカーが事前に動作確認済みのオプション製品（有償）があります。 それを「 Application Recovery Kit 」略して「 ARK(アーク) 」と呼びます。 ARKを使うことで、他のHAクラスタ製品でありがちな、ミドルウェアをHAクラスタ制御する為のスクリプトの作成がいらなくなるんです。 もちろんARKは、サイオステクノロジーがしっかり動作検証してくれてるから、スクリプトの設計や作成、テストが必要ないので、作業工数の短縮にも繋がるんだよ。 ARKを使えば面倒くさいスクリプトを書かなくて良いのはとても便利ね どんなミドルウェアに対応したARKがあるのか？ それ！とても気になるところだよね。 ではどんなミドルウェアに対応したARKがあるのか見てみましょう！ カテゴリ 対応ソフトウェア 対応OS Linux Windows データベース OracleDB 〇 〇 PostgreSQL 〇   SQL Server   〇 DB2 〇   MySQL 〇   データ連携/転送/Mail基盤 HULFT 〇 ※ライセンスは無償提供 保守のみ有鬚 〇 ※ライセンスは無償提供 保守のみ有鬚 IIS   〇 ※本体に無償で同梱 NFS Server 〇   ジョブ JP1/AJS – Manager 〇 〇 JP1/AJS – Agent 〇 〇 その他 WebSphere MQ/IBM MQ 〇   Logical Volume Manager (LVM) 〇   Device Mapper Multipath 〇         よく使われるミドルウェアに対応しているのね 有償のARKがないミドルウェアでも大丈夫！ う～ん　このリストにないミドルウェアはどうすれば良いんだろう？ そうだね。このリストに書いていないミドルウェアをLifeKeeperで保護したいって時もあるよね。 そんな時は大きく二つの方法があるよ！ （１）Quick Service Protection（QSP）を使って簡易的に保護する （２）Generic Application Recovery Kit（Generic ARK）を使ってスクリプトを作りこんで保護する （１）のQSP（キューエスピー）を使った方法については、スクリプトを作成することなくGUIによる設定をするだけで、簡単にサービスの起動/停止/監視を行うことが可能だよ （２）の Generic ARK（ジェネリックアーク）を使って保護する方法は、サイオステクノロジー謹製のサンプルスクリプトをベースに、手の込んだチェック機構などを実装することもできるんだ QSPやGenericARKで保護した実績のあるアプリケーションはこんなにあるんだよ（一例） カテゴリ 対応ソフトウェア 対応OS Linux Windows データベース MariaDB 〇   FUJITSU Software Enterprise Postgres 〇 〇 PowerGres HA 〇   EDB Postgres 〇 〇 データ連携/転送/Mail基盤 DataSpider 〇 〇 ACMS E2X 〇   AsteriaWarp 〇 〇 samba 〇   監視 Zabbix 〇   A-AUTO 〇 〇 その他 Apache 〇 〇 Tomcat 〇   SVF 〇 〇     こんなに実績があるなら 有償のARKがなくても安心ね   そうは言っても、なんかARKって難しそう。。。 有償のARKとか、GenericARKとか出てきたけどちょっと難しそう 聞きなれない言葉だから難しく感じちゃうよね。 じゃあARKについて簡単に触れておくね。 ARK(含むGenericARK)には、以下の４つの機能があるんだ 起動スクリプト(restore) アプリケーションを起動する 停止スクリプト(remove) アプリケーションを停止する 監視スクリプト(quickCheck)*1 アプリケーションが正常かどうか監視を行う（オプション） 回復スクリプト(recover)*1 監視処理で異常を検出した場合、実行してアプリケーションのリカバリーを行う（オプション） *1 スクリプトは任意での組み込み。restore, remove スクリプトだけでリソース作成は可能 この表を見て、勘の良い人はピンときたかもしれないけど、ミドルウェアの起動、停止、回復（再起動）の処理は、完全にLifeKeeperで制御するんだ。だから例えばWindowsのサービス画面では、該当のミドルウェアは「手動」起動にしておく必要があるよ。 OSでは「手動」起動にしておくのは覚えておきたいポイントね 監視処理で、リターンコードが0なら正常、それ以外なら異常と判断して、次の処理を決めるというのが、ARKの役割なんだ。 へ～　ARKの処理って意外とシンプルなんだ。安心したよ まとめ ここまで、LifeKeeperのオプション製品であるARKの概要についてご説明しました。 ・有償ARKがあれば簡単にLifeKeeperで保護できる ・有償ARKがないミドルウェアでも、QSPやGenericARKを使えば保護できる ・ARKの機能はたった４つ（起動、停止、監視、回復） 次回は、AWSなどのパブリッククラウド環境でLifeKeeperが有効な理由をお伝えしますね。お楽しみに。

こんにちは、SCSK株式会社の池田です。 みなさん、HAクラスタウェアの「 LifeKeeper（ライフキーパー） 」という製品をご存じですか？ 「LifeKeeper」は、OS自体や、Red hat Enterprise Linux や Windows Server上の任意のアプリケーションの可用性を高める、今流行りの BCP対策 （※）ぴったりの製品なんです！ （※）BCP：Business Continuity Planningの略で事業継続計画のこと 今日は、この「LifeKeeper」についてご紹介しますね LifeKeeperってナニモノ？？ LifeKeeperとは、サイオステクノロジー社が販売する 日本国産 (※)のHAクラスタウェアです。 （※）Linux版の開発主体が日本国内に、Windows版の開発主体は米国にあります。 「サイオステクノロジー」という会社名を始めて聞くかたもいらっしゃるかと思いますが、四半世紀以上前の1997年に創業、黎明期のLinuxを推進するビジネスからスタートして以来、今回ご紹介するLifeKeeperの開発やOSSに強みを持つ、東京に本社を置く企業なんです。 弊社とは、2004年12月にパートナー契約を結んで以来20年近くに渡って、LifeKeeperに関する技術情報の共有を密に図りつつ、時には共同開発検証するなどして歩んできました。 さてもう一つ聞きなれない「HAクラスタウェア」というキーワードが出てきました。 解りやすく説明しますと、 まず２台のサーバを用意して、片方を稼働系(Active)、もう片方を待機系(Standby)として構成しておきます。 普段ユーザは稼働系を使ってるんですが、稼働系サーバのミドルウェアで障害が発生した時に、待機系でミドルウェアを起動して、接続先のIPアドレスも待機系に移すことでシステムの継続性を担保するミドルウェアのことなんです。 イメージにするとこんな感じです。 一番左の絵が正常時の状態で、クライアントは稼働系サーバに接続していますね。次に真ん中の絵で稼働系サーバに障害が発生しています。それを検知した待機系サーバでミドルウェアを起動させるんです。クライアントは同じIPアドレス(VirtualIP(バーチャルアイピーって言います))に接続しているから、一度は接続が切れますが、待機系サーバに切り替わったことには気が付かないんです。 この切り替わりの処理のことを「 フェイルオーバー 」と言うんです。 サーバが１台だけですと、障害が起きた時にシステムが使えなくて、お客さんも困るし、運用保守する人も急いで復旧させないといけないから焦ってしまいますよね。 LifeKeeperがあれば、そんな不安も一気に解消ね！ どうしてLifeKeeperがお薦めなの？ 数あるHAクラスタの中でも、LifeKeeperの強みってなんだろう HAクラスタ製品はいろいろとあるけれど、LifeKeeperが優れているポイントがいくつかあるよ （１）コア課金と違って、サーバ単位の課金だから、スケールアップもしやすいよ （２）様々なアプリケーションに対応したオプション製品があるから構築が早くて安価だよ （３）GUIが判りやすいから、運用しやすいよ （４）サポートが全て日本語で受けられるよ （５）Linux版は開発元が日本にあるから、要望が受け入れられやすいよ 開発元が日本っていうのが安心ね どんな時にフェイルオーバーが起きるの？？ LifeKeeperがあれば、お客さんもシステム運用する人も皆が安心できることが解りましたね。 さて次は、どんなことをきっかけにフェイルオーバが起きるのかを解説します。 フェイルオーバーのきっかけとなるチェックは大きく２つあります。 （１）対向サーバの死活状態チェック （２）自サーバ上のミドルウェアの死活状態チェック （１）の対向サーバの死活状態チェックのイメージ コミュニケーションパスと呼ばれる回線を使って、相互に状態をチェックしていて、サーバが応答しない時や、なんらかの原因でコミュニケーションパスが切れた場合に障害と判断して、フェイルオーバが発動するんです。 お互いにサーバの状態を確認しているんだね   （２）の 自サーバ上のミドルウェアの死活状態チェックのイメージ 自サーバ上のミドルウェアの死活状態をチェックして、正常ステータス以外の場合に障害と判断します。まず自サーバ上で対象ミドルウェアを再起動して、それでも復旧しない場合はフェイルオーバが発動します。 自サーバ上のミドルウェアの状態を確認しているのね どんな環境で使えるの？ LifeKeeperは、オンプレミス環境や仮想環境はもちろん、Amazon Web Services(AWS)を始めとするパブリッククラウドでも可用性を向上するのに有効なんです。 まとめ ここまで、LifeKeeperの概要についてご説明しました。 ・2台のサーバで構成し、障害時はフェイルオーバすることでシステムを継続利用できる ・チェック方法は、相互にサーバの死活チェックと、自サーバのミドルウェアの死活チェック ・オンプレ、仮想環境はもちろん、最近はパブリッククラウドでも採用 次回は、どんなミドルウェアの可用性を高めることができるかをお伝えしますので、お楽しみに。

今回は、Catoクラウドの肝となるPoP(Point of Presence)についてご紹介します！ PoP(Point of Presence)とは PoPとは、インターネットを介してCatoクラウドのサービスを利用するためのアクセスポイントです。 世界中に自前のPoPを配備することで、グローバルでサービスを展開しています。 2023年6月時点のPoP数は80拠点以上、2024年にはPoP数を120拠点にする計画となっており、 既に日本には、東京(2箇所)と大阪(2箇所)の合計４箇所配備されています。さらに、2023年中には北海道(札幌)がリリース予定です。 日本のPoP ※2023年11月時点 ・東京 第一PoP（Tokyo） ・東京 第二PoP（Tokyo_DC2） ・大阪 第一PoP（Osaka） ・大阪 第二PoP（Osaka_DC2） PoP上でネットワーク機能とセキュリティ機能を実装しているため、ユーザは最寄りのPoPに接続することで、いつでもどこでもセキュアなネットワークを高速に利用できます。 PoPについてはこちらの記事でも紹介されておりますのでご参照ください。 世界初のSASEプラットフォーム Catoクラウドとは？ Cato Networks社 の Catoクラウド（ケイトクラウド）についてご紹介します。 Catoクラウドは世界初のSASEのサービスであり、強固なセキュリティとシンプルな運用管理を実現します。 blog.usize-tech.com 2023.08.15 PoPのアドレス ユーザはPoPに接続し、Catoクラウド経由でインターネット接続した際、インターネットへの出口はCatoクラウドのPoPになります。 出口のアドレス（以下「Egress IP」とする）については、PoPにてCatoのグローバルIPアドレスがランダムに割り当てられます。 Catoが日本のPoPで取得しているグローバルIPアドレスはこちらをご確認ください。 ※JPNIC（Japan Network Information Centre）ではなく、上位のAPNIC（Asia Pacific Network Information Centre）から取得しているアドレスです。 Production PoP Guide – Cato Learning Center (catonetworks.com) ここで少し余談です。 Egress IPのご説明をすると、「ランダム割り当てなので、Egress IPは毎回変更されてしまうのか？」とご質問をいただくことが多いですが、Egress IPは固定することが可能です。 このEgress IPの固定設定は、Microsoft 365やBoxなどのクラウドサービス、またはその他SaaSサービス、特定Webサイトで、ある特定のアドレスからのアクセスを制御している場合などに役立ちます。 Egress IPに関する詳細は別記事にて詳しくご説明しております。 CatoクラウドにおけるEgress IP（送信元IP、出口IP）について CatoクラウドにおけるEgress IPについて解説します。 blog.usize-tech.com 2023.08.22 メンテナンス・障害情報 CatoクラウドではPoPの設備維持のために定期的にメンテナンスが行われます。 メンテナンスによる通信断は一般的に 約30秒 です 。 ※メンテナンスの内容によっては数分に及ぶ可能性もございます。 そのため、定期メンテナンスは業務影響の少ない時間帯での実施が予定されており、日本の場合は午前1時から午前3時に実施されるようスケジュールされています。 ※緊急メンテナンスなど例外もございます。 以下サイトからCato PoPのメンテナンスや障害に関する情報が確認できます。 https://status.catonetworks.com/ SUBSCRIBEより、通知の設定も可能です。 現在、電話やメールに加えてSlackやTeamsでも通知が可能となっているようです。 最適経路の選択 経路選択の仕組み 世界中にPoPが配備されているとお伝えしましたが、通常Catoクラウドへ接続を開始すると、自動的にユーザのロケーションに最も近い最寄りのPoPに接続されます。 実際に、iOSの端末にCatoクライアントをインストールし、東京都内からCatoクラウドへ接続を行ってみました。 接続PoPをCMAにて確認してみると、東京 第二PoP（Tokyo_DC2）に接続されていることがわかります。 日本からの接続の際、通常はこのように日本のPoPに接続されます。 これは、SocketやCatoクライアントが、Steeringサーバから提示された複数の経路候補の中から最も近い経路を選択する仕組みとなっているためです。 Steeringサーバは、SocketやCatoクライアントから最適経路の問い合わせを受けると、ユーザのロケーションやPoPの稼働状況から複数の経路候補をSocketおよびクライアントへ提示する仕組みとなっています。 まとめると以下のような流れです。 経路選択の仕組み １．SocketやCatoクライアントが、Steeringサーバに対してDNS Queryで最適経路の問い合わせを実施 ２．Steeringサーバが、SocketやCatoクライアントに対して接続候補となるPoPリストを提示 ３．SocketやCatoクライアントは、提示された各PoPへ対し、53/udp, 443/udpパケットを送信し最寄りのPoPを確認 ４．SocketやCatoクライアントは、最寄りのPoPへ接続を開始 経路選択時のトラブル例と回避策 ここからは、経路選択時に発生し得るトラブル例と回避策について解説していきます。 トラブル例 経路選択時には、以下2つの事象が発生することがあります。 遠方のPoPに接続する 通常Catoクラウドへ接続を開始すると、自動的にユーザのロケーションに最も近いPoPに接続されますが、稀に遠方のPoPに接続され、ネットワーク接続遅延を引き起こすことがあります。   実際に、東京都内からドバイのPoPに接続するよう設定をしてCatoクラウドへ接続を行ってみると、5秒程度接続に時間がかかりました。東京 第二PoP（Tokyo_DC2）に接続した場合1、2秒程度でCatoクラウドに接続ができるため、遠方のPoPに接続すると若干ではありますが遅延が発生するようです。  海外のPoPに頻繁に接続される場合は、ご利用中のISPのIPアドレスが海外（日本以外）になっている可能性がありますので、IPロケーションサイト等で国（Country）をご確認ください。 IP Address Lookup | Geolocation Lookup a geolocation of an IP address including latitude, longitude, city, region and country. Compare the data from multiple IP location providers. www.iplocation.net                  PoPの切り替わりが頻繁に発生する ユーザのロケーションに最も近いPoPに接続ができても、接続PoPが頻繁に切り替わることによりネットワークが不安定になることがあります。 PoPの切り替わり時には、瞬断～数秒程度の通信断が発生する可能性があるため、PoPの切り替わりが頻繁に発生すると通信が不安定になります。 速度低下・パケット損失・遅延・PoPメンテナンス等によりSocketと最寄りのPoP間の接続性が不安定になると、上記のようなトラブルが発生する可能性があります。 このようなトラブルが発生した際は、接続PoPを任意のPoPに変更および固定すること改善される場合がありますので、設定方法をご紹介いたします！ 回避策 接続PoPの変更・固定は、Site(拠点)単位・モバイルユーザ単位で設定することができますので、それぞれ設定方法をご紹介します。 Site(拠点)を指定のPoPに接続する 設定箇所：Network＞Sites（指定のサイトを選択）＞Site Configuration＞General ＞Preferred PoP Locations    優先的に接続させたいPoPを”Primary”と”Secondary”の2つまで指定することができます。   「Only connect to the Preferred PoP Locations」にチェックを入れると、”Primary”と”Secondary”に指定した優先接続PoPにのみ接続するよう制限することが可能ですが、指定したPoP以外には接続されなくなります。 例えば、図のようにPrimary locationを東京 第二PoP（Tokyo_DC2）に、Secondary locationを大阪 第二PoP（Osaka_DC2）に設定すると、東京 第二PoP（Tokyo_DC2）と大阪 第二PoP（Osaka_DC2）のPoPへの接続性に問題が発生した場合でも、東京 第二PoP（Tokyo_DC2）と大阪 第二PoP（Osaka_DC2）にしか接続ができないということになります。 通常時、何か特別な理由がなければ「Only connect to the Preferred PoP Locations」のチェックは外しておいた方が良いと言えます。 モバイルユーザを指定のPoPに接続する Catoクライアントを起動後、メニューからSettingsを選択し、「MANUAL POP」をONにします。 「PoP SERVER IP」に接続させたいPoPのアドレスを手動で入力します。 私はドバイのPoP(140.82.197.1 )を指定してみました。    設定ができたらホーム画面に戻ってCatoクラウドに接続させ、メニューのStatsにて接続PoPを確認します。 設定した通り、ドバイのPoPに接続できることが確認できました。 Appendix Socketが優先接続PoP以外のPoPに接続した場合、 Socket は優先接続PoPに再接続します。 デフォルトでは60分間待機してから、自動的に優先接続PoPに再接続しますが、再接続するまでの待機時間はカスタマイズが可能です。      再接続までの待機時間は、アカウント単位・Site(拠点)単位で設定することができますので、それぞれ設定方法をご紹介します。 アカウント全体に反映する 設定箇所：Network＞Connection SLA  前述の通り、デフォルトでは60分間となっていますが、変更したい場合は自由に待機時間を変更します。 また、図のように「Disable」を選択すれば自動的に再接続させる機能を無効にすることもできます。 特定Site(拠点)に反映する 設定箇所：Network＞Sites（指定のサイトを選択）＞Site Configuration Connection SLA  図のように「Override Account Settings」にチェックを入れ、アカウント全体の設定方法と同様に設定を行います。 「Override Account Settings」にチェックを入れると、アカウントの設定を上書きすることができます。 つまり、アカウントの設定より特定サイト(拠点)の設定が優先されます。 まとめ 今回は、PoP(Point of Presence)についてご紹介しました。 この技術ブログ（TechHarmony）の他にもFAQサイトでよくあるご質問やCato クラウドのアップデート情報を公開しておりますので、是非ご参照ください！ よくあるご質問 | Cato Cloud ケイトクラウド - SCSK Cato SASE Cloud Platform. powered by SCSK cato-scsk.dga.jp

この記事を書いている担当は、いわゆるレガシーなインフラエンジニアです。 ネットワーク機器や物理サーバ、また回線やデータセンタといった物理寄りの構築・運用を担当してきましたが、ここ数年はAWSやAzureそしてSASEと、クラウドインフラに仕事が移ってきています。 そんな担当から見てCatoクラウドはどうなのか、率直に思うところを書いてみたいと思います。 Catoクラウドの良いところ 一元化された管理画面はとても便利 Catoクラウドは、ネットワーク・セキュリティのオールインワンサービスです。1つの管理画面ですべての機能が操作・確認できます。 従来は、例えば拠点を1つ新設するとなると、その拠点に置くルータを設定し、対向となるデータセンタ側のネットワーク機器に設定追加し、さらにファイアウォール等のポリシーを追加し…、と複数の機器での設定が必要となり、かつ機器ごとの知識を持っている必要がありました。 Catoでは、拠点はほぼゼロタッチで接続でき、ルーティングもセキュリティポリシーも、すべて管理画面からGUIで設定できます。この手軽さはすごいです。実際に、多拠点ネットワークの構築において拠点展開の工数を大幅に減らすことができました。 なお、他の製品では、機能ごとに管理画面が分かれていてリンクが貼られているだけだったり、UIが統一されておらず操作方法がばらばらといったものもありますが、この点Catoは全機能がよく統合されていると思います。 すべてのログが1つの画面で検索できる また、Catoではすべてのログが1つのログ管理画面に集約されています。これは運用者にとって革新的です。 これまでは、例えば特定のユーザで特定の通信ができないという問題が発生した場合、ファイアウォールに入ってブロックされていないかログを見て、次にIPSやProxyのログを見て…というように、いくつもの機器を確認する必要がありました。ログを一元管理するようなソリューションもありますが、異なるベンダの異なる機器のログを集約すると、ログのフィールドが最大公約数的に丸められており、結局実機を見る必要がある…といったことも多かったです。 この点、Catoクラウドは、セキュリティログも接続記録も、すべてが「Events」に一元的に集約されており、ユーザ名と日時で絞り込みをかけるだけで、そのユーザにその時何があったのかを知ることができます。 筆者も当初は、一元化することでログのフィールドが複雑化して、内容を読み解くのが大変では…?と思ったのですが、そうでもありませんでした。ログ毎に必要なフィールドのみが表示されるので、複雑ではないです。 ログ(Events)については、以下の記事もご参照ください。 Catoクラウド Eventsの確認方法 CatoクラウドのEvents画面の見方、ログの絞り込み方について解説します。 blog.usize-tech.com 2023.08.22 ルーティングの設計が不要 Catoクラウドでは、基本は拠点がCatoクラウドへ接続するのみのシンプルな構成となり、すべての経路制御はCatoクラウド側で行うため、ユーザがルーティングを意識する必要がなくなります。 複雑な構成にしない限り、経路制御の知識が全く無くてもネットワークが組めるということです。 冗長構成を組むのが簡単 拠点の回線を二重化したり、機器を2台置いてActive/Standby構成にすることはよくありますが、Catoではこれがとても簡単に設定できます。 従来は、各回線や機器の優先度を設計し、Config作成・設定し、実際に意図どおりに切り替わるかを複数パターンでテストし…といったプロセスを踏んでいましたが、Catoではそれらが自動設定されるため、バックアップ側の回線やSocketを接続し、管理画面から数クリックするだけで冗長化構成が完了します。 細かな融通が利かせられない面はありますが、回線・機器の故障時にもユーザが気づかないレベルで切り替わるため、通常の利用には十分です。 Catoクラウドでも楽にはならない点 仮に社内ネットワークをCatoクラウドにした場合にも、変わらず手がかかる点もあります。 セキュリティ設計・運用は従来どおりやる必要がある Catoクラウドの各種セキュリティ機能では、デフォルトで推奨設定が入っていますので、そのままでも不審な通信はBlockし、安全に利用可能です。 しかしながら、実際の運用においては、自社のセキュリティポリシーによって設定をデフォルトから変える必要があったり、日常的にユーザや部署ごとの個別のルールに対応したりといった、セキュリティ運用業務が発生するかと思います。それはインフラがCatoクラウドになっても同様にやっていく必要があります。 また、Catoクラウドにてセキュリティインシデントを検知した際、その後の対応をどうするかといった部分も、セキュリティ運用として決めておく必要があります。 このあたりは、Catoでも既存インフラでも同じように準備が必要です。 やはり足回り回線は最重要 Catoクラウドは優れたサービスですが、接続にはインターネット回線が必須です。 回線が不安定だったり、十分な速度が出なかったりすると、Catoクラウドへの接続に問題が生じ、業務通信が不安定になったり、利用できなくなってしまいます。 回線の選定や管理運用は、昔も今も変わらず重要です。 Catoクラウドのちょっと困る点 従来インフラと比べて、Catoが少し厄介だなと感じる点もあります。 ブラックボックスな面がある Catoクラウドはサービスである以上、利用者が触ることのできる範囲に限界があります。 例えばなにか通信が想定どおり通らないことがあったとして、従来のルータやファイアウォール等の物理機器が存在する場合には、その機器でDebugやパケットキャプチャを取って調べるといったことをやってきましたが、Catoではこれがほぼできません。 ユーザが確認できるのはWebUIの情報に限られており、詳細はCato社へ問い合わせるしかありません。 各機能の仕様は公開されていますが、細かな動作については回答を得られない場合もあり、正直もどかしく感じることもあります。 SocketにCLIでログインできない Socketへのログイン手段はGUIのみとなってしまっており、CLIが利用できません。コンソールポートは動作しているのですが、利用者にはログインが許可されていません。 GUIの情報には限りがあるため、何かあったときに自分で切り分けができないという点で、なかなかもどかしいです。個人的には、自分の手元のネットワーク機器はCLIでログインして状態確認をしたいです。 ベンダ依存となる これは一口に良し悪しをいうことができない内容ではありますが、ベンダーロックイン状態となることについて、留意しておく必要があります。 Catoに限らず、SASEはネットワーク・セキュリティをまるごとサービス提供元に依存する形となるため、信頼できるサービス提供元を選ぶことが重要です。 サービス提供元の規模・体制などをしっかりと確認し、納得した上で利用したいものです。 使いこなそうとするとキャッチアップが必要 Catoクラウドは、毎週アップデートや追加機能がリリースされています。 有償・無償問わず次々と新しい機能が出るため、その恩恵を受けようと思うとリリース情報にキャッチアップする必要があり、これがなかなか大変です。 なお、当社ではCato社のアップデート情報を、日本語で補足も加えて配信しておりますので、ぜひご参照ください。 リリースノート | よくあるご質問 | Cato Cloud ケイトクラウド - SCSK リリースノートについて cato-scsk.dga.jp よくあるご質問 -リリースノート 最後に 世の中の様々なサービスが”所有”から”利用”に向かっている現在(※)、ネットワークとセキュリティの”利用”と言えるSASEは、急速に一般化していくと考えています。 ※例えばDVDやCDがメディア購入→レンタル→サブスクと移り変わったように ここ10年でパブリッククラウドが一般化し、サーバを誰でもWebUIから数分で建てられるのが当たり前になったように、ネットワークとセキュリティもまた、そうなっていくことでしょう。 今後はSASEも、APIの開放やIaC(Infrastructure as Code)対応が進み、もしかするとマルチクラウドのように、マルチSASEが一般化するかもしれません。 我々SCSK Catoクラウドチームも、進化し続けるSASEや関連テクノロジーの一歩先を行き、手軽になっていく高度な機能をどのように統合・活用し、ビジネスに役立てていくかといった視点でご提案ができるよう、日々精進してまいります。

こんにちは、SCSKの木澤です。 先日、VPCにおける大きなアップデートが発表されました。 Multi-VPC ENI Attachments aws.amazon.com EC2から複数のVPCに対してENIを接続できるようになったよ、という話です。 オンプレミスのネットワーク設計経験者であれば、この話を聞いて「管理用VPCが作れるようになったな」と感じることでしょう。 実際私自身もAWS初心者の頃は管理用のネットワークが構成できないことが気になっていました。 ですが、VPCにおいては安易に管理用VPCを設置すべきではないと考えています。 その理由を下にまとめたいと思います。 オンプレミスネットワーク設計のセオリー オンプレミスにおけるネットワーク設計経験が無い方もいらっしゃると思いますので、丁寧に解説したいと思います。 今回は下図のような一般的なWeb3層のシステムのネットワークを設計することにします。 サービスネットワークの設計 Webサーバはインターネットから直接HTTP(S)のアクセスが届き、より外部からの攻撃を受けやすい状況にあります。 アプリケーション層やデータベースはより安全に守りたい、そのためWebサーバはDMZとして別セグメントに置くことが望ましいとされています。 HTTPS TLS復号処理のオフロードや冗長化を考慮するとこのようなネットワーク（論理）構成を採ることが一般的となります。 ロードバランサを1アーム（ELB同様、Webサーバと並列に設置）にするか否か、DBのセグメントを更に分けるのかどうかなど、更に選択の余地があります。 DBサーバクラスタ間の接続に別セグメントが推奨される場合もあります。 管理用ネットワークの追加 さて、単純にサービスを提供するのであればここまでで良いのですが、実際には運用を考慮する必要があります。 運用を考慮すると、下のような構成にすることが一般的です。 サーバの裏側に管理用ネットワークが追加されました。 以下の観点（背景）のため追加されることが多いかと思います。 監視 対象サーバ等と安定した通信を行う必要があります。 また監視はデータセンター提供ベンダー側が管轄することも多いため、責任分界のため表のサービスネットワークとは分離したいというニーズが出てくることもあります。 バックアップ データのバックアップ・サーバ全体のシステムバックアップ、両方のニーズがあります。 バックアップのトラフィックは重いため、バックアップ中のサービス影響を避けるためネットワークを分離することが望ましいです。 メンテナンス サーバへのメンテナンス等のためのログインも考慮する必要がありますが、障害時にも安定してログインできる必要があります。 またセキュリティの考慮のためインターネットから分離し、閉域網経由でアクセスできることが望ましいため、ネットワークを分離します。 （さらに踏み台サーバを設置し、経由しないとメンテナンスできないようにすることが通常と思いますが） これらの理由のため、管理用ネットワークを設置することが望ましいというわけです。 マルチVPC ネットワークアタッチメントについて さて、今回のアップデートについて触れたいと思います。 EC2インスタンスに紐付くプライマリVPCとは別のVPCにも足を伸ばし、接続できるようになったというアップデートになります。 今回は下図のように、単純に２つのVPCに接続した構成を作ってみます。 構成を簡略化するためにパブリックサブネットにEC2インスタンスを設置しています。 手順 まず、追加ENIを作成します。 EC2インスタンスと同一のAZである必要があります。 追加されたENIのIDを把握しておきます。 続けてEC2インスタンスに追加ENIをアタッチしますが、マネジメントコンソールでは別VPCのENIをアタッチできません。 （2023年11月7日現在。いずれ解決されるものと思いますが） そこで、CloudShellを用いてAWS CLIでアタッチを実施します。 クラスメソッド大瀧さんの記事を参考にしました。ありがとうございます。 複数のVPCにEC2インスタンスを接続する | DevelopersIO ども、大瀧です。本日、Amazon EC2にアップデートがあり、複数のVPCにEC2インスタンスを接続できるようになりました。 試してみた様子をご紹介します。 AWS管理コンソールではENIが表示されない 手順としては、 … dev.classmethod.jp 複数VPCに接続されたEC2インスタンスの動作 今回はテストということで以下のVPCに接続されたEC2を起動しました デフォルトVPC（172.31.0.0/16、接続サブネット 　172.31.0.0/20） 追加VPC（10.101.0.0/16、接続サブネット　10.101.2.0/24）※IPv6有効 EC2から見たネットワーク状態は以下の通りで、確かに両VPCに接続されたNICが有効になっています。 ルーティングテーブルはこのような表示になっています。 両VPCのルーティングテーブルが反映され、デフォルトルートが２つ見えてしまっています。 このルーティングテーブルのままでは追加VPC側CIDR宛のルーティングテーブルが定義されておらず適切に通信ができません。 追加VPC側でルーティングができるよう、スタティックルートの設定を追加します。 これで追加VPC側でも他AZのサブネットと通信可能になります。 $ sudo route add -net 10.101.0.0 netmask 255.255.0.0 gw 10.101.2.1 (宛先CIDR) (サブネットマスク) (宛先ゲートウェイ) 同様に、下図のように追加VPC側でVPC Peeringを行った場合でも、OS上のルーティングテーブルを正しく設定すれば構成可能であることを確認しました。 本アップデートに関するAWS発表内容の通り、OS上の設定で複雑な構成を組むことができ柔軟なネットワーク構成を組めそうです。 Tips：本機能でVPC間のEC2インスタンス移行は可能なのか？ さて、本アップデートの情報に触れた際、私はこのように感じました。 追加ENIを付けてから、デフォルトのENIを削除すれば VPC間の移行が可能では？ VPC間でEC2インスタンスを移行する際は一旦AMI作成した後にインスタンス再作成する必要があります。 これが面倒だなと感じていたので、付け替えが可能になれば楽になるな、という横着ですw ですが、あいにくこれは不可でした。デフォルトで付与されているENIはデタッチできません。   EC2における管理用VPC設置の是非 さて新機能に触れたところで、話を戻して管理用VPCを設置することについての是非について考えたいと思います。 EC2運用管理手法の振り返り 上記にてオンプレミスネットワークにおいては管理用ネットワークを設置する理由として、主に３つの理由（監視・バックアップ・メンテナンス）があると書きました。 これらについて、EC2においては設置が必要かどうか考えてみます。 監視 EC2においてはCloudWatchによるメトリクス監視・エージェント監視が標準です。 別途サードパーティーの監視サービスを利用し、エージェント経由で監視することもあるでしょう。 これらはインターネットゲートウェイ、あるいはVPCエンドポイント経由でパブリックネットワークにあるマネージャと通信するため、管理用VPCは不要となります。 但し下図のように統合監視用のAWSアカウントを設けて管理用（監視用）VPC経由で監視したいというニーズがあるかもしれません。 この構成は検証の結果から理論上は可能であることを確認しました。 今まで本ニーズに関しては、VPCを分けずに普通にPeeringしていたかと思います。 そのため特にVPCを分ける必要性は感じませんが、監視アカウントが別オーナーである場合など選択の可能性があるのは否定しません。 後述するリスクを踏まえて判断すれば良いものと思います。 バックアップ EC2のバックアップについては通常、EBSのスナップショットで取得するかと思います。 このトラフィックはサービスネットワークを通りませんので、トラフィック影響を排除するためにネットワークを分離する必要はありません。 データバックアップを行う場合はサービスネットワークを共用しますが、余程のことがない限り帯域を圧迫することは無いはずです。 メンテナンス サーバへのログインを行う際、Linuxインスタンスへの接続はEC2 Instance Connectあるいはセッションマネージャを利用して接続することが推奨です。（Windowsインスタンスであれば AWS Systems Manager – Fleet Manager ） 何れにせよ、サービスネットワークを経由せずセキュアに接続できることが特徴です。 VPCを分割する必要はありません。 AWSインフラについて 仮想化技術 なぜこれらの運用管理機能がマネージドで提供できるのか、念のためおさらいします。 クラウドサービスにおいては、そもそも仮想化技術がベースになっていることが歴史的背景としてあります。 クラウドでは各ユーザーの設定は論理的なものとして自由に作成・削除ができますが、それを実現するために物理ハードウェア間ではユーザから見えないところで網の目のようにネットワークが張り巡らされています。 バックアップや監視についても同様で、ユーザーから見えない範囲のネットワークで実現しています。 この背景からも、ユーザ側で別途管理用ネットワークを設ける必要が無いということになるわけです。 出展： AWS Blackbelt Online Seminar(EC2) マイクロセグメンテーション AWSに関わらずパブリッククラウドにおいてはネットワーク仮想化(SDN)の機構が採用されています。 最大の特徴として、マイクロセグメンテーションにおける論理分割が可能なことが挙げられます。 AWSにおいては、セキュリティグループを用いて論理分割が可能です。冒頭でオンプレミスネットワークにおいては境界型防御や責任分界の観点でネットワークを分離すると説明しましたが、パブリッククラウドにおいては、そもそもその必要は無い。AWSにおいてはVPC内でセキュリティグループ等で論理分割することがベストプラクティスとなります。 最大の違いはこのネットワーク設計のアプローチにあると言えます。 ゼロトラストの原則を理解する - AWS の規範的ガイダンス セキュリティモデルの基盤となるゼロトラストの中核となる一連の基本原則について学んでください。 docs.aws.amazon.com 管理用VPC設置のリスク 上述の検証結果から理論的には管理用ネットワークを設置することが確認できましたので、設置することに関して制約はありません。 但し、以下のリスクを踏まえて判断をすべきと考えます。 セキュリティのリスク やはり管理用VPCを経由して各インスタンス間が接続されていることによるセキュリティリスクを考慮すべきと思います。 セキュリティグループを用いて制御は可能ですが、接続しないことに越したことはありません。 構成が複雑化することによるトラブル これはオンプレミスの場合にも同様ですが、複数ネットワークを整備することによりルーティングが複雑化することで想定外の動作をしトラブルの要因になることがあります。 できるだけベストプラクティスに則ってネットワーク構成して行きましょう！   まとめ 新機能であるMulti VPC ENI Attachmentの機能についてご紹介させていただきました。 長くなりましたが、私としての結論は 「管理VPCの設置は理論上はできるが避けるべき」 です。 オンプレミスとクラウド流のネットワーク設計方針の本質的な違いを振り返る良いきっかけとなりました。 ありがとうございました。

こんにちは。SCSKの山田です。 Dropboxから新しいドキュメント管理・共有・追跡プラットフォームであるDocSendの提供が始まりました。 今回はこのDocSendについてご紹介いたします。 DocSendとは DocSendの特徴 DocSend は、 1 つのリンクで以下のすべて実現します。 安全なデータ提供 ドキュメントや動画など共有したいデータを安全に外部に共有します。 メールの添付ファイルも必要なくなります。 閲覧状況の分析 共有データが閲覧されたか、どの部分に興味を持たれているか可視化されます。 複数データの一元化 複数ドキュメントを一箇所にまとめて共有できます。 共有された側はまるで書庫から資料を取り出すように必要なデータにアクセス出来ます。 また以下についても活用できます。 バージョン管理の問題を解消 ドキュメントを分析する機能 安全に共有する機能 電子署名で契約締結までの時間を短縮 Docsendの使用方法 具体的な使い方の流れとしては、以下の通りです。 ドキュメントを DocSend にアップロードする Dropbox や他のアプリケーションから DocSend にファイルを簡単にアップロードできます。 ドキュメントの制限を設定および更新する 透かし機能やパスワードを設定しドキュメントのセキュリティを強化することができます。 コンテンツを安全に共有し、アクションを促す メールに添付する手間を省きすべてのドキュメントへのアクセスを、カスタマイズした 1 つのリンクで共有できます。 ドキュメントを追跡し、フォローアップする ドキュメントを詳細に分析します。 取引をより早く成立させる Dropbox Signとは別に電子署名機能が組み込まれています。 Dropboxでは、ファイル共有/リンク共有/Transferなどの共有方法がありますが、DocSendは基本リンクでの共有になります。 一般的には資料を共有してもその後相手がどう扱ったかまでは追うことができませんがDocSendでは追跡が可能です。 DocSendの分析機能 DocSendで一番注目すべきは分析機能かと思います。 通常、メールでの資料送付ではニーズや相手の興味の有無を知ることは難しいですが、分析機能から送付した資料がどのように読み込まれているかを詳しく知ることができます。 具体的に滞在時間/地域情報/訪問数/再生時間などの情報が詳細にとれます。共有したドキュメント・動画の開封率、相手がどのページをどのくらいの時間見たか、飛ばしたかを知ることができるほか、誰かが資料を確認していることをリアルタイムで知らせてくれるメール通知もあります。 組織内で利用する際は、部下や生徒に確認しておくよう依頼した資料に、きちんと目を通しているかのチェックができます。見たか見てないかだけでなく、100％確認したかまで確認できるため、課題レポートや課題図書を見ているかによって正しい評価ができます。 また、地域情報や訪問時間は、大規模災害が起きた際、企業や学校が出した案内を従業員・学生が見れているか、つまり安否確認として役立つことも期待できます。 企業同士で利用する際は、キャンペーンのプレゼン資料や営業提案書を無事に共有するだけでなく、資料の閲覧状況とタイミング、興味・関心度をしっかりと分析することができます。 これにより戦略的に顧客をフォローアップし、より的確に契約締結・満足度向上につなげることができるのではないでしょうか。またエンゲージされた見込顧客を特定し新たなステークホルダーや意思決定社の発掘により、潜在的なビジネスチャンスを得ることにも役立つかもしれません。 また、仮想データ ルーム（VDR：Virtual Data Room）という複数のドキュメントを一つの場所にまとめることができる機能もあります。ここから一つののリンクで複数の資料を安全共有できます。 今までは使用言語が英語のみでしたが、この度日本語を含む14言語にも対応しました！   DocSendデモ どのくらいの詳細なデータが取れるのか、実際に使ってみます。 まずこちらがDocSendにログインした画面になります。 右上「コンテンツをアップロード」からデータをDocSendにアップロードできます。 ここに保存されるデータをDocSendの機能を使って共有ができます。   今回はこちらの「ログイン手順」という動画をアップロードしました。 こちらを共有して、相手がどのように内容を確認したか見ていきます。 画面右上「リンクを作成」からリンク作成をして、そのリンクを共有します。   下記画面のようなリンクに対しての設定画面が出てきますので、適切な条件を付けていきます。 閲覧にメール アドレスを必須とする：閲覧者はメール アドレスを入力しないとドキュメント を閲覧できません。 ダウンロードを許可する：閲覧者はファイルをダウンロードできます。 期限：リンクの有効期限 パスコード：パスワードの設定 アクセスを制限：ドキュメントについて、どの訪問者への表示を許可する、またはブロックするかを一覧表示します。メール アドレスを個別に指定することもドメインごとに指定することもできます。 メール認証：閲覧者は自分のメール アドレスに送信された安全なリンク経由で本人確認しないと ドキュメント を閲覧できません。 動画では以下の設定も可能です。 バックグラウンド動作時は一時停止にする ミュート時は一時停止する 再生速度の変更を無効にする 早送りを無効にする   リンクが作成できたのでメールやチャットで共有します。 共有前にDocSendを確認するとアクティビティのアクセス数が０で誰も見ていないことが確認できます。 共有相手にリンクを開いて動画を閲覧してもらいます。 リンクを開いた画面は下記画像のようになります。 記録確認のために、動画を飛ばしたり、倍速にしてもらいました。   動画の閲覧をしてもらった後に再度Docsendを確認すると、アクセス数が1に代わっているのが確認できます。   こちらの結果は以下のように確認できます。 まず閲覧時間ですが、全体55秒の動画に対して31秒だけ見たことが確認できます。 色の帯がないところは動画内で飛ばした箇所になります。 下画像の黒い吹き出し部分では、再生した速度が1倍で通常通りに閲覧していることが確認ができます。         以下部分では再生した速度が2倍であるk十や、音をミュートしていることが確認ができます。   PPT資料だと以下のような結果を確認できます。 各ページごとに資料見た時間がわかります。                 まとめ 実際にDocSendを使ってみましたが、かなり詳細に記録がとれていました。 共有相手がどこに興味を持ったか、どこを飛ばしたかを確認できると営業活動や社内教育に非常に役立つと思います。 また、管理・共有・分析が高いセキュリティの一つのリンクで完結できるのがとても効率的です。 企業や学校などでぜひご活用ください。 以下DocSendのリンクです。実際に見てみてください。 DocSend - Simple, intelligent, modern content sending DocSend helps you communicate more effectively by telling you what happens to content after you send them and letting you keep control in real time. docsend.com

はじめに Cato社が提供しているCASB機能は、クラウド環境におけるセキュリティ対策を行うための機能です。 CASBとはCloud Access Security Brokerの略で、クラウドサービスにアクセスする際のセキュリティを担保するために導入されます。 Cato社のCASB機能では、主に以下のような機能が提供されています。 クラウドアプリケーションの可視化 セキュリティイベントの評価と分析 アプリケーションの制御 データの検出と保護 このような機能により、クラウド環境におけるセキュリティリスクを抑え、セキュリティ対策の強化を図ることができます。また、Cato社のCASB機能は、柔軟性が高く、複数のクラウドサービスに対応しているため、多様なクラウド環境に適用することができます。   上記CASB機能のうちアプリケーションの制御は、Catoクラウドの「Application Control」で実施できます。 本記事ではCASB機能のApplication Controlの設定方法や実際にどのような制限ができるのかについて解説していきたいと思います。   CASBについての詳細は以下技術ブログに記載がございますので、ご確認いただければと思います。 CatoクラウドのCASBについて – TechHarmony (usize-tech.com)   Application Controlでできること CatoクラウドのApplication Controlではどのようなことができるのかご紹介させていただきます。 Catoクラウドでは数多くのアプリケーションおよびサービスが登録されており、それらを制御することが可能となっております。  登録されているアプリケーションの中でも、主要なアプリをピックアップし、Catoクラウドでどのような制御ができるのかご紹介いたします。 No. アプリケーション名 主な制御内容 1 Adobe Creative Cloud ファイルのアップロードやダウンロード 2 Amazon Web Services EC2インスタンスへのアクセス制御 3 Box ファイルのアップロードやダウンロード 4 Dropbox ファイルのアップロードやダウンロード 5 Evernote ノートのアップロードやダウンロード 6 Facebook メッセージの送受信や投稿 7 GitHub リポジトリへのアクセス制御 8 Gmail メールの送受信や添付ファイル 9 Google Apps ドキュメントやスプレッドシートのアクセス制御 10 Google Drive ファイルのアップロードやダウンロード 11 Apple iCloud ファイルのアップロードやダウンロード 12 LinkedIn メッセージの送受信や投稿 13 Microsoft Office 365 ドキュメントやスプレッドシートのアクセス制御 14 Salesforce データのアクセス制御 15 Slack メッセージの送受信や投稿 16 X/Twitter ツイートの投稿やメッセージの送受信 17 WebEx オンライン会議や画面共有 18 Zoom オンライン会議や画面共有 ファイルのアップロードダウンロード、メッセージの送信などが制御できる内容になっています。 上記アプリ以外にも、Catoクラウドは常にアプリケーションの更新を行っているので、これからもアプリ数・制御内容が拡充していくと思われます。   Cato社のサンプル設定 2023年10月以降に新規でCASB機能をご契約いただいたアカウントに関しまして、デフォルトでCato社の設定例が入っております。 投入されている設定を参考にし、既存設定を自社用にアレンジしていくことで効率よくアプリケーションを制御することが可能となります。 以下が設定内容となります。 No. ルール内容 対象アプリ 1 Microsoftへのログインを指定のテナント名のみ許可する   Microsoft   2 Microsoftへログインする上記以外のテナント名はログに残す 3 OneDriveのログインを対象のテナント名のみ許可する OneDrive 4 上記以外のテナント名の場合ログに残す 5 個人用のOneDriveテナントの場合ログに残す 6 Gmailアプリを使用してメールに添付ファイルを追加する際、ログに残す Gmail 7 オンラインストレージカテゴリのアプリを監視し、次のいずれかの条件に一致した場合、ログに残す。 Catoリスクスコアが3より高い(4以上) ISO 27001を満たしていない Online storage apps 8 Twitter/X にて全ての投稿をログに残す Twitter/X 9 OpenAIへのログインは、指定されたユーザとテナント名のみ許可する OpenAI 10 上記以外のユーザ、テナント名の場合ログに残す 11 OpenAIへのログインにてthird-partyの場合ログに残す 12 Google Driveにて許可されたフォルダの表示を制限する Google Drive 13 Google Driveにて許可されていないフォルダをログに残す   設定方法について それでは、実際のApplication Controlの設定方法について解説していきます。 CMA（管理画面）上で設定を入れる際は以下の画面にて操作を行っていきます。 Securty＞Application Control＞Application Control Policy＞App Control Rule   では、投入する設定項目についてみてみましょう。 まず、Applicationにて制御したい対象のアプリを選択します。 「Any Cloud Application」にてクラウドアプリケーション全体や、カテゴリーなどで大枠のアプリを選択することも可能です。   次に、Activitiesで制御したい内容を選択します。 内容については、選択したアプリケーション毎に異なってきます。 メール機能のアプリなどであれば、メール送付やファイル添付の制御が可能でしたり、アプリケーションへのログイン制御なども可能になってきます。 制御内容を①許可、②拒否、③監視（ログに残す）のいずれか選択してルールを反映させれば設定完了です。   実際に設定をいれてやってみた 設定の投入方法がわかったところで、上記設定例を参考にしつつ、実際にルールを設定して想定通りの制御ができるか確認してみましょう。 今回は、「Microsoftへのログインを制御する」というルールを設定してみます。 ルールは以下の内容を設定します。 1 Microsoftへのログインにてユーザー名に「SCSK」が含まれているものを許可する 2 Microsoftログインをブロックする まず、許可する対象のユーザー名を指定し、ログイン許可のルールを設定します。その配下に、Microsoftへのログインをブロックする設定を入れます。これにより、許可したユーザー名以外のアカウントをブロックし、ログイン制御をすることができます。   今回は「SCSK」のユーザー名が含まれるアカウントでログインを実施してみます。 SCSKドメインのアカウントでMicrosoftへログインをしていきます。 当然ながらログインができ、以下のようなログが出力されました。   続いて、ドメイン名に「SCSK」が入っていないアカウントでログインを実施してみます。 すると、想定通りMicrosoftへのログイン画面にてblockの表示がされました。該当のログは以下のようなものになります。   このようにアプリケーションへのログインの制御などが可能となります。   まとめ CatoクラウドのCASB機能にはセキュリティ強化、アプリケーション利用状況の可視化を行うことができ、柔軟性があるため多様なクラウド環境に適用することができ、セキュリティ対策を一元管理することができます。 CatoクラウドではCASB機能はセキュリティオプションとなりますが、クラウド環境においてセキュリティを強化するために、CASB機能を有効活用することをおすすめします。

はじめに Cato クラウドでは、Internet Firewall のベストプラクティスとして QUIC プロトコル (QUIC Service と GQUIC Application) の通信をブロックすることが推奨されています。これはドキュメントの Internet and WAN Firewall Policies – Best Practices のページだけでなく、他の複数のページにも同様のことが書かれています。 また、CASB 機能の1つである Application Control を有効にすると、QUIC プロトコルをブロックするルールが Internet Firewall の上位に自動的に作られるようにもなっています。 本記事では QUIC プロトコルの仕組みについて簡単に触れつつ、QUIC プロトコルをブロックすべき理由やブロックすることで生じる問題点について解説します。 QUIC プロトコルとは QUIC とは、2021年5月に IETF にてインターネット標準として定められた通信プロトコルであり、TCP と同様に信頼性の高い通信を行うためのトランスポート層のプロトコルです。現在のところ、トランスポート層として QUIC を利用するアプリケーションプロトコルとしては、HTTP/3 のみインターネット標準として定められています。 QUIC は比較的新しいプロトコルではあるものの、10年ほど前に Google が公開したプロトコルが基となっており、既に多くの Web サイトや Web サービスが QUIC および HTTP/3 を採用しています。また、主要なブラウザ (Google Chrome, Microsoft Edge, Mozilla Firefox など) も HTTP/3 に対応しており、ご自宅などの環境では HTTP/3 でインターネットと通信が行われているはずです。 実際、私の自宅から Google のトップページを Google Chrome で表示させ、デベロッパーツールで通信の内容を確認すると次のようになっていました。 デベロッパーツールの “Protocol” という列が “h3” となっているリクエストは、HTTP/3 で通信されたことを表しています。(“h2” は HTTP/2 で通信されたことを表しています。) また、私個人として Web サイトを AWS の CloudFront という CDN サービスを用いて公開していますが、CloudFront も HTTP/3 に対応していますので、私個人の Web サイトも HTTP/3 でアクセスできるようにしています。 このように、HTTP/3 は普通のインターネット利用者が気付かない形でどんどん普及しており、その下では QUIC プロトコルによるトラフィックも多く流れているという状況にあります。 QUIC プロトコルの構造 QUIC と HTTP/3 についてもう少し詳しく説明します。 QUIC はトランスポート層のプロトコルですが、IP ではなく UDP の上に構築されたプロトコルです。すなわち、IP パケットのデータ部に UDP パケットがあり、UDP パケットのデータ部に QUIC パケットがあるという構造となっています。   この構造により、ネットワーク機器が QUIC を扱えなくても、UDP 通信の制御により QUIC 通信の可否を制御できるようになっています。HTTP/3 は通常 443 番ポートを利用して通信しますので、アウトバウンド方向に UDP 443 番ポートの通信が許可されていれば、HTTP/3 通信を行えるということになります。 QUIC プロトコルをブロックすべき理由 さて、Cato クラウドでは Internet Firewall で QUIC プロトコルをブロックすることが推奨されていますが、ブロックしないとどのような問題が起きるのでしょうか。 ドキュメントの Internet and WAN Firewall Policies – Best Practices のページには次の一文が記載されています。 Since the QUIC protocol works over UDP 443, encapsulated HTTP traffic is not parsed. Cato クラウドは HTTP/3 通信の内容を解析しないと述べられています。つまり、HTTP/3 通信に対して Cato クラウドは TLS インスペクションを行わず、Application Control や DLP といった CASB の機能も働かないということを示しています。 CASB 機能は Cato クラウドの魅力の1つでもあり、この機能が働かないというのは困ります。そのため、QUIC プロトコルをブロックして HTTP/3 通信を行えないようにすることで、CASB 機能が働く HTTP/2 や HTTP/1.1 による通信に限定しようというのが先の Internet Firewall のブロックルールの意図です。 この対応は理想的な内容ではありませんが、Cato クラウドの現状の仕様を考慮すると最善の対応であると思います。 ブロックすることで生じる問題点 通信できなくならないか Cato クラウドで QUIC プロトコルをブロックすることで、別の問題が発生しないか気になるのではないでしょうか。これについては、問題は概ね発生しないと断言して良いと思います。 通常、ブラウザは最初に HTTP/2 や HTTP/1.1 で Web サーバと通信を開始し、レスポンスに Web サーバが HTTP/3 に対応しているかどうかを示すヘッダ (Alt-Svc ヘッダ) が含まれていれば、次からは HTTP/3 で通信しようとします。しかし、QUIC プロトコルがブロックされているとブラウザは Web サーバとの間で HTTP/3 接続を確立できないため、引き続き HTTP/2 や HTTP/1.1 で通信を行います。そのため、QUIC プロトコルをブロックしても Web サーバと通信ができなくなることはありません。 ただし、ブラウザ以外のソフトウェア (モバイルアプリケーションや PC 上で動作するデスクトップアプリケーションなど) については上記の限りではありません。通信を HTTP/3 にアップグレードしたり、HTTP/3 で通信できずにフォーバックしたりする仕組みはソフトウェアの実装依存ですので、ソフトウェアが適切に作られていないと正常に動作しないケースがあるかもしれません。 その他懸念点 他にもいくつか懸念点はあります。 最大の懸念点としては、Cato クラウドのベストプラクティスに従い QUIC プロトコル (QUIC Service と GQUIC Application) をブロックするようにしたとき、QUIC 以外の通信もブロックされてしまわないかという点です。UDP 通信の中身が QUIC かどうかを確実に見分ける方法はないため、Cato クラウドが QUIC ではない何らかの UDP 通信を誤ってブロックしてしまう可能性があります。 試しにインターネット上で 443 番ポートで適当な UDP サーバを起動し、Cato クラウド経由でアクセスしたところ、QUIC ではないデータを送信しているにもかかわらずブロックされてしまいました。 QUIC プロトコルをブロックするというルールが実際にどのような条件に該当する通信をブロックするのか仕様として公開されていないため、誤ったブロックの可能性を拭えません。そのため、イベントログにて誤ったブロックが発生していないか定期的に確認し、誤ったブロックが見つかれば明示的に Allow するルールを追加するといった運用が必要となります。 また、些細な懸念点としては、ブラウザが HTTP/3 通信を試みてから HTTP/2 や HTTP/1.1 にフォールバックするまで、通信が待たされてしまうという点です。実際にどの程度の時間待たされるのかはブラウザ次第であり、過去には数十秒待たされることがありましたが、現在はほとんど気にならない程度になっていると感じています。他にも、通信できない無駄な UDP トラフィックが発生するというのも少し気になります。 これについては、Cato クラウドが HTTP/2 や HTTP/1.1 通信のレスポンスヘッダから Alt-Svc ヘッダを除去してくれれば、ブラウザが HTTP/3 通信を試みることがなくなりますので、Cato クラウドの機能改善を待ちたいところです。 まとめ 本記事では QUIC プロトコルをブロックするというベストプラクティスに関して、技術的な背景や新たな課題について整理しました。 現状では CASB 機能を正しく働かせるために QUIC をブロックすべきなのは間違いありませんので、ベストプラクティスに従ってルールを追加することを推奨します。一方で、誤ったブロックが発生する可能性などの懸念点もありますので、利用者側でイベントログをもとにした運用も必要となってきます。 QUIC という新しい通信プロトコルは現在は HTTP/3 でしか利用されていないものの、他のアプリケーションプロトコルで活用するための議論が IETF で活発に行われています。将来 HTTP/3 以外で QUIC 通信が増えてくると、Cato クラウドの機能やベストプラクティス自体もまた変わってくるはずですので、通信プロトコル界隈の動向には今後も目を離せませんね。

こんにちは。SCSKの丸山です。 本日は、データベースの性能問題にお悩みの方必見！の新サービスのご紹介です。 マルチデータベース　パフォーマンスチューニングサービス｜SCSK株式会社 データベースの性能にお困りの方に、複数のDBに精通するエンジニアがデータベースの性能改善支援を実施します。 www.scsk.jp データベースの性能問題、システム開発をされた方は一度は経験があるのではないでしょうか。 開発中のシステムのDB性能が出ない… データ量が増えてきて性能が低下し始めた… SQLの改善方法がわからない… などなど、私たちのチームにも、データベースの性能に関する相談がよくあります。そこで、新しくデータベースのチューニングに関するサービスをリリースいたしました。その名も、 「SCSK マルチデータベース　パフォーマンスチューニングサービス」 データベースの性能にお困りの方に、複数のデータベースに精通するエンジニアがデータベースの性能改善支援を実施するサービスです。これまでも、データベースの性能問題については様々な事案を対応してきましたので、改めてサービスとして皆様に届けやすいサービスとなっております。 特徴としては、Oracle DB, MySQL, PostgreSQLをベースとしたDBについて オンプレクラウド問わずに対応できる こと※。 複数のデータベースに精通したエンジニアが対応 しますので、Oracle DBからPostgreSQLなどへの 異種DB移行時における性能問題にも対応可 能 です。 「データベースのことよくわからないので、まるっとお任せしたい」 というアプリ担当者から、 「原因のあるSQLは特定できているが、改善方法がわからない」 というDB担当者まで、幅広く対応するためのメニューをそろえております。 気になる方は、是非以下URLをご参照ください。 マルチデータベース　パフォーマンスチューニングサービス｜SCSK株式会社 データベースの性能にお困りの方に、複数のDBに精通するエンジニアがデータベースの性能改善支援を実施します。 www.scsk.jp 以上となります。 ※ただし、商用サポートがあるものを前提とします。  

みなさん、こんにちは。SCSKで飼われているひつじです。 最近は涼しくなってきて過ごしやすいです。 AWS Well-Architectedフレームワークが２年ぶりにメジャーアップデートされました。 結構いろいろ変わったので見てみましょう。 なにが変わったの？ 柱の構成要素である「ベストプラクティス」がトータルで増えました。 内容が更新されたものもあります。かなりの数です。さすがメジャーアップデート。   運用上の優秀性の柱 更新された質問 ワークロードをサポートする準備が整っていることはどうすれば確認できるでしょうか? どのようにデプロイのリスクを軽減しますか? どのように欠陥を減らし、修正を容易にして、本番環境へのフローを改善するのですか? ワークロードと運用イベントはどのように管理しますか? 優先順位はどのように決定すればよいでしょうか? ビジネスの成果をサポートするために、組織をどのように構築しますか? オペレーションの正常性をどのように把握しますか? オペレーションを進化させる方法 組織の文化はビジネスの成果をどのようにサポートしますか? 削除された質問 どのようにワークロードを設計して、その状態を理解できるようにするのですか? ワークロードの正常性をどのように把握しますか? 新しい質問 組織でワークロードのオブザーバビリティを活用する方法を教えてください。 ワークロードにオブザーバビリティを実装する方法を教えてください。 セキュリティの柱 更新された質問 ネットワークリソースをどのように保護しますか? 保管時のデータをどのように保護していますか? どのようにデータを分類していますか? コンピューティングリソースをどのように保護していますか? 転送時のデータをどのように保護していますか? ユーザー ID とマシン ID はどのように管理したらよいでしょうか? セキュリティイベントをどのように検出し、調査していますか？ 人とマシンのアクセス許可はどのように管理すればよいでしょうか? インシデントの予測、対応、復旧はどのように行いますか? ワークロードを安全に運用するには、どうすればよいですか? 新しい質問 設計、開発、デプロイのライフサイクル全体を通じて、アプリケーションのセキュリティ特性をどのように組み込み、検証すればよいのでしょうか?   信頼性の柱 更新された質問 ネットワークトポロジをどのように計画しますか? どのように信頼性をテストしますか? コンポーネントの障害に耐えるようにワークロードを設計するにはどうすればよいですか? ワークロードリソースをモニタリングするにはどうすればよいですか? ワークロードを保護するために障害分離をどのように使用しますか? 災害対策 (DR) はどのように計画するのですか? データはどのようにバックアップするのですか? どのようにワークロードサービスアーキテクチャを設計すればよいですか? 障害を緩和または耐えるために、分散システムの操作をどのように設計しますか? サービスクォータと制約はどのように管理しますか? 変更はどのように実装するのですか? 障害を防ぐために、分散システムの操作をどのように設計しますか? パフォーマンス効率の柱 更新された質問 ワークロードに適したクラウドリソースとアーキテクチャパターンを選択する方法を教えてください。 削除された質問 データベースソリューションをどのように選択していますか。 どのようにネットワーキングソリューションを選択するのですか? ストレージソリューションをどのように選択していますか? リソースが稼働していることを確実にするためのリソースのモニタリングはどのように行いますか? ワークロードを進化させるためにどのように新機能を取り込んでいますか？ トレードオフをどのように使用するとパフォーマンスが向上するのですか? コンピューティングソリューションはどのように選択するのですか? 新しい質問 ワークロードのパフォーマンス効率を高めるために、どのようなプロセスを使用していますか? ワークロード内のデータを保存、管理、アクセスする方法を教えてください。 ワークロードでネットワーキングリソースを選択して設定する方法を教えてください。 ワークロードでコンピューティングリソースをどのように選択して使用しますか? 信頼性の柱 更新された質問 ネットワークトポロジをどのように計画しますか? どのように信頼性をテストしますか? コンポーネントの障害に耐えるようにワークロードを設計するにはどうすればよいですか? ワークロードリソースをモニタリングするにはどうすればよいですか? ワークロードを保護するために障害分離をどのように使用しますか? 災害対策 (DR) はどのように計画するのですか? データはどのようにバックアップするのですか? どのようにワークロードサービスアーキテクチャを設計すればよいですか? 障害を緩和または耐えるために、分散システムの操作をどのように設計しますか? サービスクォータと制約はどのように管理しますか? 変更はどのように実装するのですか? 障害を防ぐために、分散システムの操作をどのように設計しますか? コスト最適化の柱 更新された質問 クラウド財務管理はどのように実装しますか? 不要なリソースをどのように削除しますか？ どのように需要を管理し、リソースを供給しますか? コストと使用状況をどのように監視していますか? コストターゲットに合わせて、リソースタイプ、リソースサイズ、およびリソース数を選択するには、どうすればよいですか? コストを削減するには、料金モデルをどのように使用したらよいでしょうか? サービスを選択するとき、どのようにコストを評価しますか? データ転送料金についてどのように計画していますか？ 新しいサービスをどのように評価していますか？ 使用状況をどのように管理しますか? 新しい質問 労力コストを評価するにはどうすればよいですか? 持続可能性 の柱 新しい質問 組織のプロセスは、持続可能性目標の達成にどのように役立ちますか? ソフトウェアとアーキテクチャのパターンをどのように利用して、持続可能性目標を目指しますか? データ管理のポリシーとパターンをどのように利用して、持続可能性目標を達成しますか? アーキテクチャでクラウドのハードウェアとサービスをどのように選択して、持続可能性目標を達成しますか? クラウドリソースを需要に合わせる方法 ワークロードにリージョンを選択する方法 まとめ 2年ぶりにメジャーアップデートで大きく内容が変わったので最新のベストプラクティスに沿ってAWS環境をより良いモノにできますね。 パフォーマンスの柱はトータルで設問が減りましたが、そのほかの柱は充足された内容になっております。 「効率化」と「充足化」の両方の性質を併せ持つアップデートだったかなと思います。 本項目を内部統制の仕組みやツールに組み込んでいる場合は大幅な改修が必要になると思うので無理せず頑張っていきましょう。