NAVERクラウドプラットフォームのゲームデータ分析エキスパート「Game Report」- 第一編:サービス紹介

f:id:navercloud:20210329120044p:plain

正確なゲームデータ分析。
ゲームのデザインからバランス調整まで。
ゲームの成功において欠かせない作業ですね!

ゲームデータ分析にとても役立つ、NAVERクラウドプラットフォームのゲーム向けビックデータ分析サービス、Game Report(ゲームレポート)がリリースされました!

Game Report(ゲームレポート)

NAVERクラウドプラットフォームのゲームデータ分析エキスパート

Game Reportは一体どんなものでしょうか?

その特徴と機能を詳しく見てみましょう。

 

Game Report(ゲームレポート)はどんなサービスですか?

f:id:navercloud:20210108155858p:plainGame Report(ゲームレポート)は、ゲーム内のすべてのデータを活用して、あらゆる指標を分析する「ゲーム向けビックデータ分析サービス」です。
このサービスを活用すると、ゲームデベロッパーはリアルタイムでゲーム内指標を確認し、データに基づいたゲームバランスを実現できます。また、売上の増減状況やユーザーの接続状況、イベント追跡、コホート分析など様々な機能を活用できます。

 

Game Report(ゲームレポート)の特徴について教えてください。

f:id:navercloud:20210108155858p:plain

Game Reportの特徴#1:ゲーム内データの深層分析

ゲーム内のすべてのデータを分析し、ユーザーのプレイ状況やアイテム消費に関する指標など様々な分析情報を提供します。
この機能を活用すると、ゲーム内バランスの最適化やレベルデザイン、ビックデータをベースとしたゲームデザインなどが実現できます。

f:id:navercloud:20210327164032j:plain

ゲーム内データの深層分析 - https://www.ncloud.com/product/game/gameReport

 

Game Reportの特徴#2:リアルタイム指標分析

接続中のユーザーの状況や売上、ゲーム内財貨、プレイパターンなどの主要指標をリアルタイムで分析し、読みやすい形で表示します。
新商品のリリースまたはアップデートの後には、各種指標やユーザーの反応をリアルタイムで確認し、成功有無と改善点を直ちに把握できます。ゲームバランスもリアルタイムで調整できます。

f:id:navercloud:20210327164102j:plain

リアルタイム指標分析 - https://www.ncloud.com/product/game/gameReport

 

Game Reportの特徴#3:コホート分析及びユーザー分析の細分化

ユーザーの特性を考慮した「カスタマイズコホート」を作成し、データをグループ別に分析できます。
OS情報や流入経路、ユーザーレベル、ゲーム内財貨の消費量などのデータをグループ別に比較分析できます。 

f:id:navercloud:20210327164143j:plain

コホート分析及びユーザー分析の細分化 - https://www.ncloud.com/product/game/gameReport

Game Reportの特徴#4:生ログビューアーサービスの提供

ゲーム分析情報の生データとゲーム開発や分析に役立つ様々な検索機能を提供します。
この機能を活用すると、ユーザーのアクセスログやアイテムの獲得・消費の履歴、ゲームコンテンツのプレイ情報まで細かく把握できます。f:id:navercloud:20210327164256j:plain
生ログビューアーサービスの提供 - https://www.ncloud.com/product/game/gameReport

 

Game Report(ゲームレポート)機能の総まとめ

このようにGame Report(ゲームレポート)は、ゲーム分析に最適化されたログセットを集約したSDKを提供しています。MMORPGやアクション、カジュアル、STG、シミュレーションなど様々なゲームジャンルにカスタマイズして活用できます。

f:id:navercloud:20210327164311j:plain

ゲーム向けビックデータエキスパート、Game Report(ゲームレポート)

特徴と機能に関する紹介は以上になります。
次の投稿では、各機能の活用方法について詳しく説明します。

 

f:id:navercloud:20210329150446p:plain

f:id:navercloud:20201209180753p:plain

大宇(DAEWOO)建設:クラウド型ドローン管制システムの運用

f:id:navercloud:20210329120031p:plain

建設現場のドローン管制システムの運用にNAVERクラウドプラットフォームのサービスがどう活用されているか見てみましょう。2021年2月4日、大宇建設とNAVERクラウドは、クラウド型遠隔ドローン管制システムの事業活性化に向けた業務協約を締結しました。韓国の建設会社としては初めて大宇建設が開発した「DWドローン管制システム」は、建設現場の工程記録や安全管理などをドローンによってリモートで撮影・モニタリングできるサービスです。

今年は、NAVERクラウドとの協業を通じて建設分野だけでなく、消防や人命捜索、海岸偵察など様々な領域でドローン関連サービスを披露する予定です!ドローン管制システムを構築した、ソン・グンモクさん(大宇建設デジタル建設チームドローン空間情報パート長)とのインタビューをご紹介したいと思います。

Q. 会社とサービスについて簡単な紹介をお願いします。

f:id:navercloud:20210108155858p:plain

こんにちは。大宇建設は現在、韓国と海外の22ヵ所の現場にてDWドローン管制システムを適用しています。大宇建設はLNG事業と土木分野で立派な海外受注実績を達成しており、韓国の住宅供給実績においても2年連続1位という成果を得ることができました。さらに、海外投資や不動産開発事業を拡大しながら、ドローン技術や電気自動車の車載用バッテリー部門など未来志向型事業の推進を通じて新たな成長エンジンの確保に取り組んでいます。

DWドローン管制システムは、ドローンを遠隔操作で自動コントロールして建設現場の工程を映像に記録します。特に「自動任務飛行」を活用すると、同じ場所と構図で映像を撮影できるため、過去に撮影した動画と比較しやすいです。このような特徴から、工程の変化過程や安全管理に必要な情報などをリアルタイムで利害関係者に提供できます。また、DWドローン管制システムは、建設現場だけでなく、消防や人命捜索、火災監視、海岸偵察など様々な領域に拡大適用できます。

DWドローン管制システムは現在、大宇建設の社内サービスとして1年以上運用されています。今年からは、NAVERクラウドプラットフォームを活用して社外向けのサービス提供も計画しています。大宇スマートドローン管制システムの紹介映像です。

 

Q. クラウドを使うことになったきっかけは何ですか?

f:id:navercloud:20210108155858p:plain

大宇建設はDWドローン管制システムサービスの継続的な拡大を図っています。サービスの拡大とともにサーバ増設が必要になるタイミングが訪れるだろうと判断していましたが、ご存知の通り、物理サーバの構築にはかなりの時間と構築費用、メンテナンス費用をかけなければなりません。そこで、短時間でサーバが構築でき、使った分だけ費用を支払うクラウドサービスを活用した方が経済的にもメリットがあると判断しました。

 

Q. 色んなクラウドサービスの中でも、NAVERクラウドプラットフォームを選んだ理由は何ですか?

f:id:navercloud:20210108155858p:plain

その理由はNAVERクラウドプラットフォームの優れたユーザービリティにあります。NAVERクラウドプラットフォームは直観的なUXとUIで構成されているため、主要機能が使いやすくなっています。これに加えて様々なサービスを同時に利用できるプラットフォーム技術は、ユーザービリティを最大限に引き上げてくれます。

それだけではありません。NAVERクラウドプラットフォームの安定したサービスに対する信頼も理由の一つと言えます。NAVERクラウドプラットフォームは、様々なセキュリティ認証を取得しており、その技術力は世界からも認められています。また、データセンター「GAK」のような韓国最大ITサービスの安定したインフラを利用しているため、自社サービスを提供する上で最高のプラットフォームだと判断しました。 

NAVERクラウドプラットフォームが安全な理由は何だど思います?

 1.クラウドの安全な利用に欠かせない情報セキュリティ認証を取得しているからだと思います。

🔒セキュリティ認証について詳しく見る

2.韓国に設けられているデータセンター「GAK」。大事なデータを海外に保管せずに済みます。

📋 データセンターについて詳しく見る

 

 Q. 現在、NAVERクラウドプラットフォームのどんなサービスを利用していますか?実際利用してみて、どのように役立っていますか?

f:id:navercloud:20210108155858p:plain

DWドローン管制システムは、NAVERクラウドプラットフォームのComputeとStorage、Networking、DBなどのインフラを利用しています。

DWドローン管制システムは映像記録物を提供するサービスで、ユーザーの接続数やトラフィックがとても流動的です。物理サーバはこのような変化に柔軟に対応できません。しかし、NAVERクラウドプラットフォームのServerを利用してからは、サービス運用中にもサーバの増設や減設が行えるためとても効率的です。NAVERクラウドプラットフォームのおかげで、サービス運用による負担を減らし、自社の環境に合わせてフレキシブルにサーバを利用できています。

また、NAVERクラウドプラットフォームのServerは僅かなクリックだけでサーバを運用できるためとても便利です。たとえば、サーバスペックの変更をはじめ、サーバデータやOSイメージの定期的なバックアップ、データ使用量やネットワークなどサーバ状態のモニタリングにも容易に対応できます。さらに、NAVERクラウドプラットフォームのServerはセキュリティ設定がデフォルトで適用されており、セキュリティ関連のコンサルティングが必要な場合は専門家からアドバイスを受けられるため、心強いです。

最近では、NAVERクラウドプラットフォームのAIサービスとマップAPIを活用しています。マップAPIを用いて建設現場や周辺の情報を容易に把握できるアプリを開発しました。また、Machine Learningサービスを通じて「ドローン映像分析システム」を研究しています。

 

Q. 今後、NAVERクラウドプラットフォームを活用してどんなサービスを提供したいと思いますか?

f:id:navercloud:20210108155858p:plain

2021年には、NAVERクラウドプラットフォームを活用して、捜索や消防、監視など様々な産業分野に向けてDWドローン管制システムサービスを提供する予定です。また、AIによる画像分析技術を取り入れて、ドローンが配信した映像の状況を自動的に把握し、危険や異常症候などの情報をユーザーに提供するサービスの開発も進めています。

このようなサービスの開発において、NAVERクラウドプラットフォームのSecurityやMedia、AI Service、Analyticsなど様々なサービスを総合的に活用できると期待しています。DWドローン管制システムとNAVERクラウドプラットフォームのコラボレーションにより、ユーザーの皆様に最高のサービスを提供できる良いチャンスが得られると信じています。

f:id:navercloud:20210108155858p:plain

大宇建設が選んだNAVERクラウドプラットフォームの強みは、ユーザービリティと信頼できるインフラ、セキュリティでした。これからもNAVERクラウドプラットフォームとドローン管制システムが様々な業界で活躍する姿を見守っていただけたらと思います! 

 

f:id:navercloud:20201209181056p:plain

f:id:navercloud:20201209180753p:plain

 

Eコマースに必要なすべて!META Commerceリリース~!

f:id:navercloud:20210224210342p:plain

こんにちは!NAVERクラウドプラットフォームです。

本日は、Eコマースに必要なすべてを備えているソリューション、META Commerce(メタコマース)商品のリリースをお伝えします。

META Commerceソリューションは、FORBIZ KOREAが10年以上にわたり300以上のプロジェクトを通じて積んだ Eコマースソリューション技術をベースに作られたEコマースソリューション。NAVERクラウドプラットフォーム上で無料提供される予定である。(出典:デジタルタイムズ、2020.11)

昨年11月のソリューション契約締結のニュースに続き、ついに!!
NAVERクラウド専用商品として発売された#メタコマース #METACommerce
一緒にチェックしてみましょう!

 

META Commerce(メタコマース)とは、どのような商品ですか?

META Commerceは、企業型ECP会社であるFORBIZ KOREAの経験やノウハウ、技術が詰まったクラウドベースの「独立型Eコマースソリューション」です。Eコマースへのアクセス方法、構築時間、コスト、人材の専門性、運営方法など、顧客が抱えている様々な問題やニーズに対して一緒に向き合っています。

META Commerceは、エンタープライズ級の設計構造と機能の専門性、NAVERクラウドのインフラをベースにした安定性と拡張性、そして自由なカスタム環境を提供し、専門家のエコシステムを形成します。

f:id:navercloud:20210225143118p:plain

META Commerceの特長#1.オープン型の無料ライセンス

META Commerceは無料ライセンスによる独立型ソリューションで、ショッピングモールをカスタマイズして構築・運営しています。

クラウドインフラのカスタマイズができることが大きな特長ですが、

カスタマイズの後にもパッチアップ(アップデート)が提供されること!忘れないでくださいね :)

META Commerceの特長#2.エンタープライズ級のソフトウェア構造設計

年間売上高500億ウォン以上規模ののショッピングモール運営の経験に基づいて、META Commerceソリューションはエンタープライズ級プロセスとして設計・検証されました!

300以上のプロジェクトで検証された大容量DB、大容量トラフィックとパッチアップ設計まで…!スタートアップから大型モールまで運営できます。(ふふっ!)

f:id:navercloud:20210225161724p:plain

独立型ショッピングモールを検討中のスタートアップから流通会社まで運営可能なMETA Commerce

META Commerceの特長#3.Ecosystemサービスを提供

META Commerceは様々なプラグインと付加サービスを提供します。ビジネス拡張のための様々なプラグインや付加サービスは、必要なときに申請、決済、承認を経てすぐに~!利用できます。開発、デザイン、マーケティングの専門家でエコシステムを構成し、顧客とパートナーがつながるようMETA Commerceが専門パートナーエコシステムを提供いたします。

 

META Commerceの利用料金について教えてください!

先にも申し上げたように、META Commerceソフトウェアライセンスは無料です!お気軽に利用してみてください。 

無料提供

付加サービスとインフラ
有料サービス

インフラ

2週間無料、2週間猶予(計1か月無料)

※ ソフトウェアライセンスは無料で提供され、クラウドインフラは無料クレジットが提供されます。

** ただし、クラウドインフラは4週間の無料提供後、有料へ切り替わります。 

META Commerceの活用事例を紹介してください! 

f:id:navercloud:20210225161730p:plain

Forbiz Korea

[優れた構築事例 - Pulmuone]

[優れた構築事例 - Barrel]

f:id:navercloud:20210108155858p:plain
以上、META Commerce(メタコマース)商品の紹介でした。
Eコマースに興味のある方なら絶対に「META Commerce」にも目がいくと思います。 *_*
独立型無料ライセンスのEコマースソリューション
META Commerceの詳細をみる

NAVERクラウドのインフラの活用によって安定性と拡張性の高い環境構築ができるMETA Commerce!
ぜひご利用ください!:D

 

f:id:navercloud:20210225161510p:plain

f:id:navercloud:20201209180753p:plain

 

API Gatewayを活用したOpen APIサービス作り

f:id:navercloud:20210224221146p:plain

皆さん、こんにちは。NAVERクラウドプラットフォームです。
本日はAPI Gateway商品についての簡単な紹介と、これを用いてOpen APIサービスを作る方法を説明します。

最近は多くのサービスがAPIの形で制御できるように開発されており、そのAPIはOpen APIの形で一般のユーザーに提供されています。例えば、NAVERクラウドプラットフォームから提供されているMapsCAPTCHAといった様々なOpen APIサービスは、API Gatewayを用いて提供されています。

このようなOpen APIを提供するには、セキュリティや認証、使用量の制御、APIバージョン及び明細書の管理、急なトラフィック増加など、考慮すべきことがたくさんあります。しかし、NAVERクラウドプラットフォームから提供されるAPI Gateway商品を利用すれば、このような点を気にすることなく手軽にOpen APIサービスを構築できます。

API Gatewayではカスタム認証、Swagger UI、API Overviewを通じてAPI Documentを管理できます。また、Stageのリリース履歴を管理してAPIバージョンを管理したり、以前バージョンにロールバックする機能やリリースしたAPIに対するSDKをダウンロードできる機能など、Open APIを運用するうえで便利な機能を提供しています。

 API Gatewayの詳細をみる 

では、これからAPI Gateway商品を用いて以下のような条件を持つOpen APIサービスの作り方を説明いたします。

▶ 発行したAPI KeyでのみOpen APIを使用するように制限

API Key別の使用量制御機能(日/月)

APIの登録・リリース

まずはユーザーガイドを参考にして、API Gateway商品に対し「API登録」と「APIリリース」を行ってください。

それからOpen APIサービスに合わせて、一部の設定を以下のとおり変更してください。

f:id:navercloud:20210225120923p:plain

Productの購入方法には、「公開 - 自主購入」と「保護 - 承認必要」があります。

▶ 公開 - 自主購入:商品のAPIを誰もが使用できます。

▶ 保護 - 承認必要:商品のAPIを使用するには、掲示者の承認が必要です。

ここでは、特定のAPI KeyでのみAPIを呼び出すよう制限する必要があるので、Productの購入方法を「保護 - 承認必要」に変更します。

f:id:navercloud:20210225120927p:plain

Productの購入方法を変更したとしても、メソッドで「API Key必要」の設定がインアクティブ状態になっていると、このメソッドはAPI Keyなしで使用できます。

よって、制限が必要なメソッドは「API Key必要」の設定をアクティブにしてください。 カスタム認証のロジックをAPI Gatewayで処理したい場合、Authorizerが利用可能ですのでご参考ください。

f:id:navercloud:20210225120931p:plain

トラフィックの急送に備えるため、StageのThrottlingはエンドポイントの可用量に合わせて設定を行ってください。この設定により、Throttling設定以上のトラフィックが発生する場合は、API Gatewayから「Throttle Limited」というエラーメッセージがリターンされます。

f:id:navercloud:20210225120936p:plain

また、Usage Planが連結されていないAPI Keyの使用を防ぐために、StageのDefault Usage Planのリクエスト処理限度を0に変更します。

 

本格的なOpen APIサービス作り

NAVERクラウドプラットフォームのOpen APIの使用方法

NAVERクラウドプラットフォームから提供される商品のOpen APIを使用するには、認証キーが必要です。認証キーの作成および呼び出し方法は、ガイドをご参照ください。

API Gatewayコンソールから提供されるすべての機能は、Open APIで提供されています。
この中からOpen APIサービス作りに必要なAPIを確認してみましょう。 

以下のAPIを使用するには、先ほど作っておいたProduct、API、StageのID情報が必要です。
リリースされたStage Documentのリンクをクリックすると、URLから必要なIDを取得できるのでご参考ください。

f:id:navercloud:20210225120941p:plain

ここからは、以下の機能を提供するために必要なAPI GatewayのOpen APIについて説明いたします。

API使用のためのAPI Keyの発行および削除

API Keyの使用量の変更および確認

API KeyのPrimary/Secondary Keyの変更

 

1. Open APIを使用するためのAPI Keyの発行および使用量の設定

以下の順序でAPIを呼び出してAPI Keyを発行し、そのAPI Keyを用いてOpen APIを使用できるように設定します。

▶  API Key作成 - Product購入

API Keyの使用量を制御するには、API KeyにUsage Planを作成して連結します。

使用量の制御は、Usage PlanにつながったStageの使用量を合算して処理されます。

複数のStageを一つの使用量として制御したい場合は、Usage Planに複数のStageを連結してください。

Usage Planを作成 - StageにUsage Planを連結する - API KeyのUsage Planを変更

 

2. API KeyとUsage Planの削除

使用しないAPI KeyとUsage Planを削除してください。

API Keyの削除 - Usage Planの削除

 

3. API Keyの使用量の変更およびキーの更新

API Key別に作成したUsage Planの設定を変更して、使用量を制御できます。

 Usage Planの修正 

API Keyの漏洩などにより、API Keyを変更する必要がある場合に使用します。

 API Keyの更新

 

4. 使用量の確認

API Keyが呼び出した使用量と日/月別の使用制限設定を確認できます。

購入したAPI Keyの使用量の確認

 

API KeyとUsage Planの最大作成数の制限

API Gatewayでは、アカウント別にAPI KeyとUsage Planを作成できる最大数が以下のように制限されています。

API Keyの最大作成数:500

Usage Planの最大作成数:300

この制限を調整したい場合、NAVERクラウドプラットフォームのお客様サポートまでお問い合わせください。

 NAVERクラウドプラットフォームにオンラインでお問い合わせる

f:id:navercloud:20210108155858p:plain

ここまで、API Gatewayを活用してOpen APIサービスを作る方法を紹介いたしました。

さらに知りたい点はコメントやNAVERクラウドプラットフォームのお客様サポートを通じてお問い合わせいただければ、回答いたします。

次回の投稿でも有益な情報を提供いたします!

引き続きよろしくお願いします。

 

f:id:navercloud:20201209180753p:plain

 

ラッシュガード韓国1位「バレル」、 トラフィックにもサーfバーダウンすることなく、売上増につながった秘訣は?

Image for postこんにちは。NAVERクラウドプラットフォームです。

今日は、ラッシュガードと言えば真っ先に浮かんでくるサーフブランド「バレル」のクラウド活用事例についてご紹介します。

Image for post

最近大きな話題を呼んだドラマ「夫婦の世界」で熱演した女優ハン・ソヒさんを新しいモデルに抜擢し、ウォータースポーツだけでなく、ヨーガやピラティス用スポーツウェア[バレルフィット]にも力を入れています。Image for post

「バレルデー」または「スウィムデー」という言葉を一度はお聞きなっていると思いますが、バレル社は毎年後半期に定期バーゲン・セールを行っています。(ちなみに、今年はレギンスデ-を用意しているとか!) 破格の割引で毎回、話題のキーワード1位となり、売上を大きく伸ばしています!

このように最近は、大規模のオンラインプロモーションが活発に行われ、消費者から評判を得ています。しかしながら、その人気と共にできるトラフィックによるサービス障害は、避けて通れない存在になってしまい頻繁に起きています。それを解決するためにクラウドを活用すれば、プロモーション中はサーバーを柔軟にスケーリングする一方で、プロモーション終了後は通常のサイズに戻すことができます。それにより、企業側は費用・運営の負担を減らせる一方で、消費者側はアプローチしやすくなります。Image for post

バレル社が大規模なトラフィックにもサーバーダウンすることなく、成功的にプロモーションを開催できたのは、クラウドインフラが大きく貢献しました。バレル社は昨年までは、韓国のある有名な電子商取引プラットフォームを介しプロモーションを進行しましたが、トラフィック急増によってサイトが麻痺してしまい、オンライン売上のほとんどは、NAVERストアファームから発生しました。バレル社は、それを教訓にしてNAVERクラウドプラットフォームに切り替え、その結果、50倍以上のトラフィックが増加したにも関わらず、サイトへの接続はスムーズで、安定的にプロモーションが行われました。

その結果、通常と比べサイトのページヴューは70倍増加、ユニークユーザー数は39倍増加となりました。

安定的なサービスの提供に向けたインフラ活用は、バレル社だけでなく、他のネット通販やネットサービス業者の方々も大変お気になるところではないかと思います。

“ バレルはどうやって大規模なトラフィックにもサーバーダウンすることなく、安定的なサービスが可能だったのか。

 通常のバレル社のウェブインフラは、ウェブサーバー2台、画像処理1台、DBサーバー2台、検索サーバー1台で構成されています。但し、プロモーションではウェブサーバー45台、画像処理2台、DBサーバー5台、検索サーバー3台に増設しました。更に、機会損失を回避し様々なコンテンツを素早く配信する「CDN」や、サーバーの性能と負荷量を考慮しネットワークトラフィックを分散させる「ロードバランサー」も使用しました。

[インフラ構成図 before]
Image for post

[インフラ構成図 after]

f:id:navercloud:20210224214427p:plain

他にもサービス中に記録されるログを一箇所にまとめて保存し、簡単に分析できる「’Cloud Log Analytics」や、様々なセキュリティ上の脅威をリアルタイムで検知する「Security Monitoring」、データを安全にバックアップできる「Backup」も活用しました。ポイントを下記の通りまとめてみました。

  • 従来と比べ20倍Scale outしたウェブサーバー
  • DBサーバーの柔軟なScale up / out
  • CDN(Contents Delivery Network)適用

サーバーダウンはせず売上はアップ!NAVERクラウドプラットフォームと一緒なら実現できます。ここまで、NAVERクラウドプラットフォームを活用することで、トラフィックの急増にも安定的なサービスができることをバレル社の事例から紹介しました。

お問い合わせは、NAVERクラウドプラットフォームの顧客サポートまでにお願い申し上げます。

ありがとうございました。

 

f:id:navercloud:20201209181056p:plain

f:id:navercloud:20201209180753p:plain

 

Terraformを活用したNAVERクラウドプラットフォームVPCインフラの構築

f:id:navercloud:20210223180106p:plain

皆さん、こんにちは。NAVERクラウドプラットフォームです。

本日は、インフラ自動化のためのIaC(Infrastructure as a Code)のオープンソースであるTerraformを活用して、VPC環境を構築する方法をご紹介します。

では、始めましょう!

VPCとは?

VPCを分かりやすく説明するために、以下のように仮定します。

  • N Companyという会社では、同じソリューションを3つのテナント(A、B、C)に提供します。
  • N Companyが管理する1つのアカウントで各テナント専用のインフラを作り、独立的にサービスを提供しています。

f:id:navercloud:20210224182206p:plain

既存のクラシック(CLASSIC)環境(VPCがない環境)だと、上図のようになります。

この環境では論理的にネットワーク環境を共有しているので、以下のような問題が生じます。

1つのアカウントでマルチテナントに対してサービスを提供する場合、各テナント間の通信が可能であるため、ACG(Access Control Group)などを通じてアクセス制御を別途設定しなければなりません。システムが複雑になると、このような設定はますます難しくなります。

各サーバのプライベートIPを直接設定することができないため、各テナントのネットワーク環境を同一に構築することはできません。

例) テナント別DBサーバのプライベートIP

  • Aテナント 10.53.1.56
  • Bテナント 10.46.12.41
  • Cテナント 10.61.51.23

上記のように同じ目的のサーバのプライベートIPがテナントごとに異なるため、テナントごとにIPアドレスを設定する必要があります。

また、サーバのプライベートIPは作成時にランダムで付与されるため、IP帯域を介したアクセス制御は難しいです。

 

では、VPCはどのようにして問題を解決してくれるのでしょうか。

NAVERクラウドプラットフォームのVPC(Virtual Private Cloud)は、パブリッククラウド上で提供される顧客専用のプライベートネットワークを意味します。

f:id:navercloud:20210224182312p:plain

N CompanyのVPC環境構築図

上記の環境でVPCを適用すると、以下のようになります。

N Companyから提供される各テナントのネットワークは、VPCを通じて完全に独立的に提供されます。すなわち、ACGを別途設定しなくても隔離されたネットワーク環境が作られます。

VPCごとに独立したIP帯がを提供されるため、サーバ作成時に希望するプライベートIPを設定できます。テナントごとに同じ設定値を利用することができ、サーバの作成前にどのようなプライベートIPを持つことになるか予測できます。

例) テナント別DBサーバのプライベートIP

  • Aテナント 10.0.1.7
  • Bテナント 10.0.1.7
  • Cテナント 10.0.1.7

Subnetを通じて希望するプライベートIP帯域を設定することができ、それによりIP帯域を用いたセキュリティ管理も効率的であることが分かります。

上記のようにVPCは隔離されたネットワークを提供することにより、管理やセキュリティ面で既存のCLASSIC環境より優れています。

VPCは他VPCネットワークと論理的に分離されており、既存の顧客データセンターネットワークと同様に実装できます。Subnet(Subnet)はVPCネットワーク空間を細分化して使用できる機能です。

VPCに関する詳しい説明は、ガイドをご参照ください。

VPCシナリオ

今回の投稿で、Terraformで構築するシナリオは以下のとおりです。

 シナリオ2. PublicPrivate Subnet

f:id:navercloud:20210224182526p:plain

  シナリオ2. PublicとPrivate Subnetの構成

上記シナリオでは、1つのVPC環境でKR-2 ZONEのPublic SubnetにFEサーバを置き、Private SubnetにWASのようなServerを1台ずつ作成します。

構造に関する理解を助けるため、構造について簡単に説明いたします。

1. VPC

ユーザー専用の仮想ネットワークで、すべてのリソースはVPC内で作成されます。例題の中のVPCは10.0.0.0/16のCIDRブロックを持ち、このVPC内では10.0.X.X形式のIPv4アドレスを65,536 (256²)個提供します。

Subnet

VPC内のアドレス範囲を指定できます。PrivateとPublicの2つのSubnetを提供します。Subnetが属するZoneを指定できます。KR Regionを基準に、KR-1またはKR-2に作成できます。高可用性のため、2つのZoneにそれぞれサービスを構築できます。

2. Public Subnet

例題では10.0.0.0/24のCIDRブロックを持ち、このサブネット内では10.0.0.X形式のIPv4アドレスを250個(Reserved IP address 6個は除く)作成できます。

Public Subnetの場合、基本的にInternet Gatewayとつながっているため、外部との通信が可能で、外部からもSubnetにアクセスできます。要塞ホストを置くのに適しています。

3. Private Subnet

例題では10.0.1.0/24のCIDRブロックを持ち、このサブネット内では10.0.1.X形式のIPv4アドレスを250個作成できます。基本的には外部ネットワークが遮断されていて、VPC内でのみ通信が可能です。しかし、NAT Gatewayを用いるとインターネットに接続できます。WASやDBといったサーバはここに置きます。

4. Internet Gateway

VPCを、外部とのインターネット通信ができるようにします。

(VPC作成時に基本提供されるため、Terraformでは当該リソースは扱いません。)

5. NAT Gateway

Private Subnetが外部との通信を行えるようにします。

(通常、OSのパッケージをアップグレードしたり、外部インターネットのAPIを呼び出すために接続します。)

Private Route Tableを介して接続されます。

6. Route Table

VPC作成時には、基本的にPublicとPrivateのルーティングテーブルが作成されます。ルーティングテーブルは、VPC内で他のインスタンスとの通信を可能にしてくれます。Publicは、Internet Gatewayとつながっていてインターネット通信を可能にし、PrivateはNAT Gatewayに接続してインターネット通信を可能にします。

7. Network ACL

セキュリティのためにACGまたはNetwork ACLを使用しますが、ACGはサーバのInbound/Outboundトラフィックを制御し、Network ACLはサブネットのInbound/Outboundトラフィックを制御できます。基本的には0.0.0.0/0ソースに対してallowされているため、セキュリティのためにACLルールの設定が必要です。

この例題で作成されるリソースは以下のとおりです。 

VPC 1個

  • Subnet 2個 (Public、Private)
  • NAT Gateway 1個
  • Network ACL 2個
  • Server 2個 (Frontend、Backend)
  • Public IP 1個

* Terraformのインストール

Terraformはこちらからダウンロードできます。

$ unzip terraform_0.14.2_linux_amd64.zip && mv terraform /usr/bin

$ terraform version # 설치 확인

Terraform v0.14.2

例題コードの構造

例題では、以下のようなファイル構造を持ちます。

$ cd terraform/tf-vpc-scenario2
$ tree
.
├── main.tf # VPCリソースを定義します。
├── security.tf # Network ACLルールを指定します。
├── versions.tf # Terraformに関連するバージョンを指定します。
└── variables.tf # variable変数を定義します。

 

当該例題コードはこちらで確認できます。

# versions.tf
terraform {
required_providers {
ncloud = {
source = "navercloudplatform/ncloud"
}
}
required_version = ">= 0.13"
}
versions.tfでは、NAVERクラウドプラットフォームProviderのバージョンを設定します。本例題ではProviderバージョンv2.0.3以降の基準で作成されました。この例題ではTerraform 0.13バージョン以降を推奨します。

variables.tf

# variables.tf
variable name_scn02 {
default = "tf-scn02"
}
variable client_ip {
default = "YOUR_CLIENT_IP" // To access ssh
}
variable access_key {
default = "YOUR_ACCESS_KEY"
}
variable secret_key {
default = "YOUR_SECRET_KEY"
}

 

このファイルではTerraformコード内でよく使われる値を変数として設定します。

リソース名を簡単に設定するため、name_scn02を設定します。この値は好きなように変更してもかまいません。

SSH接続時に、Network ACL設定のためのclient_ipを入力します。

ポータルで認証キー情報をaccess_keyとsecret_keyに入力します。

(この値はポータルにログインして、マイペ > 認証キ管理より確認できます。)

main.tf

このファイルにはproviderの設定とVPCを含むほとんどのインフラコードが含まれています。

# main.tf
provider "ncloud" {
support_vpc = true
region = "KR"
access_key = var.access_key
secret_key = var.secret_key
}

 

まずはncloud providerの設定を行います。ここではsupport_vpcをtrueに設定して、VPC環境を使用します。(重要)

1. VPC (ncloud_vpc)

f:id:navercloud:20210224193825p:plain

VPC (Virtual Private Network)の作成

始めに、ncloud_vpcリソースを用いてVPCを定義します。当該リソースに関するガイドはこちらで確認できます。

上図のように、VPC作成時には基本的にInternet Gateway、Route Table、Network ACL、ACG(Access Control Group)が作成されます。

# main.tf
# VPC
resource "ncloud_vpc" "vpc_scn_02" {
name = var.name_scn02
ipv4_cidr_block = "10.0.0.0/16"
}

 

ipv4_cidr_blockは10.0.0.0/16に設定します。10.0.X.Xのような形式のIPv4アドレスを65536個(256 x 256)持てることを意味します。VPCの名前はvariable.tfにあるname_scn02をヒントにして「tf-scn02」と作成される予定です。

2.Subnet & Network ACL (ncloud_subnetncloud_network_acl)

f:id:navercloud:20210224193913p:plain

Private SubnetとPublic Subnetの作成


図のようにPrivate SubnetとPublic Subnet、それからNetwork ACLを定義します。

Public Subnetは基本的に提供されるInternet Gatewayを通じて外部との通信を行うため、Frontend(要塞ホスト)サーバを置いてサービスを提供します。
Private SubnetはVPC内でのみ通信が可能で、BackendサーバのWASやDBサーバなどを置いてサービスを提供します。

# main.tf
# Public Subnet
resource "ncloud_subnet" "subnet_scn_02_public" {
name = "${var.name_scn02}-public"
vpc_no = ncloud_vpc.vpc_scn_02.vpc_no
subnet = cidrsubnet(ncloud_vpc.vpc_scn_02.ipv4_cidr_block, 8, 0) // "10.0.0.0/24"
zone = "KR-2"
network_acl_no = ncloud_network_acl.network_acl_02_public.id
subnet_type = "PUBLIC" // PUBLIC(Public)
}
# Private Subnet
resource "ncloud_subnet" "subnet_scn_02_private" {
name = "${var.name_scn02}-private"
vpc_no = ncloud_vpc.vpc_scn_02.vpc_no
subnet = cidrsubnet(ncloud_vpc.vpc_scn_02.ipv4_cidr_block, 8, 1) // "10.0.1.0/24"
zone = "KR-2"
network_acl_no = ncloud_network_acl.network_acl_02_private.id
subnet_type = "PRIVATE" // PRIVATE(Private)
}
# Network ACL
resource "ncloud_network_acl" "network_acl_02_public" {
vpc_no = ncloud_vpc.vpc_scn_02.id
name = "${var.name_scn02}-public"
}
resource "ncloud_network_acl" "network_acl_02_private" {
vpc_no = ncloud_vpc.vpc_scn_02.id
name = "${var.name_scn02}-private"
}

 

SubnetはVPCの中に作られるため、vpc_noを指定する必要があります。

上で設定したVPC ncloud_vpc.vpc_scn_02.vpc_noに設定します。ZONEはKR-2と定義します。

Terraformでは、cidrsubnet(10.0.0.0/16, 8, 1)のような関数を用いてCIDRブロックを計算できます。

詳しい内容はcidrsubnet Functionをご参照ください。

 

Subnet作成時にはNetwork ACLが必要になるので、network_acl_noを指定します。

VPC作成時に基本提供されるNetwork ACLに設定することもできますが、PrivateとPublicのACL設定を別々にするために、それぞれ作りました。

セキュリティのためのACLルール設定は、7. Network ACLで説明します。 

3. Server (ncloud_server)

VPC環境でサーバを作成できるSubnetが完成しました。では、ここからはServerの作成方法に進みます。

f:id:navercloud:20210224194213p:plain

各SubnetにServerを作成する
# main.tf
# Login Key
resource "ncloud_login_key" "key_scn_02" {
key_name = var.name_scn02 }
# Server
# for Front-end (bastion) server
resource "ncloud_server" "server_scn_02_public" {
subnet_no = ncloud_subnet.subnet_scn_02_public.id
name = "${var.name_scn02}-public"
server_image_product_code = "SW.VSVR.OS.LNX64.CNTOS.0703.B050"
login_key_name = ncloud_login_key.key_scn_02.key_name
//server_product_code = "SVR.VSVR.STAND.C002.M008.NET.SSD.B050.G002" }
# for Back-end (WAS) server
resource "ncloud_server" "server_scn_02_private" {
subnet_no = ncloud_subnet.subnet_scn_02_private.id
name = "${var.name_scn02}-private"
server_image_product_code = "SW.VSVR.OS.LNX64.CNTOS.0703.B050"
login_key_name = ncloud_login_key.key_scn_02.key_name
//server_product_code = "SVR.VSVR.STAND.C002.M008.NET.SSD.B050.G002"
} 

 

VPC ServerはSubnetを指定する必要があります。例題では、それぞれPublicとPrivate Subnetを参照しました。

server_image_product_codeを通じてサーバ画像を設定することもできますが、例題ではCentOS 7.3に指定しました。

サーバ画像コードをインポートする方法は、タソス:ncloud_server_imagesをご参照ください。

 

server_product_code設定でサーバのスペックを指定することができます。入力しないと、最も低いスペックに設定されます。

そのコードはタソス:ncloud_server_productsをご参照ください。

resource "ncloud_public_ip" "public_ip_scn_02" {

server_instance_no = ncloud_server.server_scn_02_public.id

description = "for ${var.name_scn02}"

}

外部からこちらのFrontendサーバにアクセスできるようにし、管理者もSSHにアクセスできるように、グローバルIP(Public IP)を上記のように設定してサーバとつなぎます。

4. NAT Gateway (ncloud_nat_gateway)

ここまででサービスのための全体図がある程度完成しました。

ところが、Private Subnetにあるサーバで外部のパッケージをダウンロードしたいのに、インターネットがつながりません。どうすればいいでしょうか。

 NAT Gatewayを通じてPrivate Subnetから外部のインターネットに接続できます。

f:id:navercloud:20210224194423p:plain

NAT Gatewayの作成
# main.tf
# NAT Gateway
resource "ncloud_nat_gateway" "nat_gateway_scn_02" {
vpc_no = ncloud_vpc.vpc_scn_02.id
zone = "KR-2"
name = var.name_scn02
} 

NAT GatewayをKR-2 ZONEに作成します。

5. Routeの設定 (ncloud_route)

しかし、NAT Gatewayを追加するだけでは外部との通信ができません。

問題は、Private Subnetで外部通信(0.0.0.0/0)がNAT Gatewayまで行けるように道を作らなければならないことです。

これは以下のようにRoute設定を通じて行います。

f:id:navercloud:20210224194541p:plain

Route 設定

ncloud_route_tableリソースを通じてRoute Tableを作成できます。

VPCで基本として作成されたRoute Tableを使用する予定です。

基本的にRoute TableはPublic用とPrivate用にそれぞれ1つずつ作成されますが、NAT GatewayをつけるためにPrivate Route Tableを参照します。

# main.tf
# Route
resource "ncloud_route" "route_scn_02_nat" {
 route_table_no       = ncloud_vpc.vpc_scn_02.default_private_route_table_no
 destination_cidr_block  = "0.0.0.0/0"
 target_type         = "NATGW" // NATGW (NAT Gateway) | VPCPEERING (VPC Peering) | VGW (Virtual Private Gateway).
 target_name         = ncloud_nat_gateway.nat_gateway_scn_02.name
 target_no         = ncloud_nat_gateway.nat_gateway_scn_02.id
}

 

destination_cidr_blockを0.0.0.0/0に指定し、このアドレスに向かうリクエストをNAT Gatewayに向かわせます。

target_typeとtarget_noは、上で定義したNAT Gatewayを参照します。

6. SSH接続とコマンドの実行

TerraformではNull Resourceを通じたSSH接続が可能で、remote-exec Provisionerを通じてls -alといったコマンドを実行できます。

以下のコードは、Network ACLルールがうまく適用されたかどうかをls -alコマンドを実行して出力します。

# main.tf
data "ncloud_root_password" "scn_02_root_password" {
 server_instance_no = ncloud_server.server_scn_02_public.id
 private_key = ncloud_login_key.key_scn_02.private_key
}
resource "null_resource" "ls-al" {
 connection {
   type = "ssh"
   host = ncloud_public_ip.public_ip_scn_02.public_ip
   user = "root"
   port = "22"
   password = data.ncloud_root_password.scn_02_root_password.root_password
 }
   provisioner "remote-exec" { // コマンド実行
    inline = [
     "ls -al",
    ]
 }
 depends_on = [
  ncloud_public_ip.public_ip_scn_02,
  ncloud_server.server_scn_02_public
 ]
}

 

ここまでコードを作成したら、サービスのためのインフラ準備全般ができたと言えますが、

セキュリティのため、さらに行うことが残っています。

security.tf

Subnet & Network ACLでNetwork ACLを作成しましたが、基本Network ACLルールはすべてのIPとportに対してallowされている状態です。すなわち、外部からSSHやサービスにアクセスしてハッキングするリスクがあるという意味です。

以下の例題では、セキュリティのためのACLルールを設定してみましょう。

 

7. Network ACL (ncloud_network_acl_rule)

NAVERクラウドプラットフォームは、VPCのセキュリティ強化に使用できるACGとNetwork ACLの2つの機能を提供します。

詳しい内容は、説明書 > NETWORKING > VPC > セキュリティをご参照ください。

まずはPublic SubnetとつながるACLルールを設定しましょう。

▶ Public Subnet:Inbound

f:id:navercloud:20210224204758p:plain

▶ Public Subnet:Outbound

f:id:navercloud:20210224204840p:plain

# security.tf
# Network ACL Rule
locals {
 public_subnet_inbound = [
   [1, "TCP", "0.0.0.0/0", "80", "ALLOW"],
   [2, "TCP", "0.0.0.0/0", "443", "ALLOW"],
   [3, "TCP", "${var.client_ip}/32", "22", "ALLOW"],
   [4, "TCP", "${var.client_ip}/32", "3389", "ALLOW"],
   [5, "TCP", "0.0.0.0/0", "32768-65535", "ALLOW"],
   [197, "TCP", "0.0.0.0/0", "1-65535", "DROP"],
   [198, "UDP", "0.0.0.0/0", "1-65535", "DROP"],
   [199, "ICMP", "0.0.0.0/0", null, "DROP"],
 ]
public_subnet_outbound = [
   [1, "TCP", "0.0.0.0/0", "80", "ALLOW"],
   [2, "TCP", "0.0.0.0/0", "443", "ALLOW"],
   [3, "TCP", "0.0.0.0/0", "9001-65535", "ALLOW"],
   [4, "TCP", "${ncloud_server.server_scn_02_private.network_interface[0].private_ip}/32", "8080", "ALLOW"], // Allow 8080 port to private server
   [197, "TCP", "0.0.0.0/0", "1-65535", "DROP"],
   [198, "UDP", "0.0.0.0/0", "1-65535", "DROP"],
   [199, "ICMP", "0.0.0.0/0", null, "DROP"]
 ]
}
resource "ncloud_network_acl_rule" "network_acl_02_rule_public" {
 network_acl_no = ncloud_network_acl.network_acl_02_public.id
 dynamic "inbound" {
  for_each = local.public_subnet_inbound
  content {
    priority = inbound.value[0]
    protocol = inbound.value[1]
    ip_block = inbound.value[2]
    port_range = inbound.value[3]
   rule_action = inbound.value[4]
  }
 }
dynamic "outbound" {
  for_each = local.public_subnet_outbound
  content {
    priority = outbound.value[0]
    protocol = outbound.value[1]
    ip_block = outbound.value[2]
    port_range = outbound.value[3]
    rule_action = outbound.value[4]
   }
  }
}

 

次は、PrivateのSubnetのACLルールを以下のように設定します。 

▶ Private Subnet:Inbound

f:id:navercloud:20210224204858p:plain

▶ Private Subnet:Outbound

f:id:navercloud:20210224204919p:plain

# security.tf
locals {
 private_subnet_inbound = [
   [1, "TCP", "${ncloud_server.server_scn_02_public.network_interface[0].private_ip}/32", "8080", "ALLOW"], // Allow 8080 port from public server
   [2, "TCP", "0.0.0.0/0", "32768-65535", "ALLOW"],
   [197, "TCP", "0.0.0.0/0", "1-65535", "DROP"],
   [198, "UDP", "0.0.0.0/0", "1-65535", "DROP"],
   [199, "ICMP", "0.0.0.0/0", null, "DROP"],
 ]
private_subnet_outbound = [
   [1, "TCP", "${ncloud_server.server_scn_02_public.network_interface[0].private_ip}/32", "32768-65535", "ALLOW"], // Allow 32768-65535 port to public server
   [197, "TCP", "0.0.0.0/0", "1-65535", "DROP"],
   [198, "UDP", "0.0.0.0/0", "1-65535", "DROP"],
   [199, "ICMP", "0.0.0.0/0", null, "DROP"]
 ]
}
resource "ncloud_network_acl_rule" "network_acl_02_private" {
 network_acl_no = ncloud_network_acl.network_acl_02_private.id
dynamic "inbound" {
  for_each = local.private_subnet_inbound
  content {
    priority = inbound.value[0]
     protocol = inbound.value[1]
     ip_block = inbound.value[2]
    port_range = inbound.value[3]
    rule_action = inbound.value[4]
 }
}
dynamic "outbound" {
  for_each = local.private_subnet_outbound
  content {
    priority = outbound.value[0]
    protocol = outbound.value[1]
    ip_block = outbound.value[2]
    port_range = outbound.value[3]
    rule_action = outbound.value[4]
  }
 }
}

上記コードでは、約24個のルールをハードコーディングするとソースコードが長くなってしまうため、localsdynamicのBlockを用いてルールを作成します。

これでTerraformコードの作成が終わりました。では実際にインフラを作成してみましょう。

リソース作成計画 (terraform plan)

$ cd terraform/tf-vpc-scenario2
$ terraform plan
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be persisted to local or remote state storage.
------------------------------------------------------------------------
An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
 + create
<= read (data resources)
Terraform will perform the following actions:
# data.ncloud_root_password.scn_02_root_password will be read during apply
 # (config refers to values not yet known)
 <= data "ncloud_root_password" "scn_02_root_password" {
    + id = (known after apply)
    + private_key = (sensitive value)
    + root_password = (sensitive value)
    + server_instance_no = (known after apply)
  }
# ncloud_login_key.key_scn_02 will be created
 + resource "ncloud_login_key" "key_scn_02" {
    + fingerprint = (known after apply)
    + id = (known after apply)
    + key_name = "tf-scn02"
    + private_key = (sensitive value)
 }
# ncloud_nat_gateway.nat_gateway_scn_02 will be created
 + resource "ncloud_nat_gateway" "nat_gateway_scn_02" {
    + description = (known after apply)
    + id = (known after apply)
    + name = "tf-scn02"
    + nat_gateway_no = (known after apply)
    + public_ip = (known after apply)
    + vpc_no = (known after apply) + zone = "KR-2" } ... 中略
Plan: 14 to add, 0 to change, 0 to destroy.
------------------------------------------------------------------------
Note: You didn't specify an "-out" parameter to save this plan, so Terraform
can't guarantee that exactly these actions will be performed if
"terraform apply" is subsequently run.

 

コードが無事作成されれば、上記のようにPlan: 14 to add, 0 to change, 0 to destroy.と表示され、実際の適用時に14のリソースが作成されることになります。では、以下のterraform applyを通じてリソースを作成してみましょう。

リソースの適用 (terraform apply)

以下のようにterraform applyのコマンドを実行してPlanをもう一度確認し、yesを入力してリソースを作成します。 

$ terraform apply
 
An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
 + create
 <= read (data resources)
Terraform will perform the following actions:
# ncloud_login_key.key_scn_02 will be created
 + resource "ncloud_login_key" "key_scn_02" {
    + fingerprint = (known after apply)
    + id = (known after apply)
    + key_name = "tf-scn02"
    + private_key = (sensitive value)
 }
# ncloud_nat_gateway.nat_gateway_scn_02 will be created
 + resource "ncloud_nat_gateway" "nat_gateway_scn_02" {
    + description = (known after apply)
    + id = (known after apply) + name = "tf-scn02"
    + nat_gateway_no = (known after apply)
    + public_ip = (known after apply)  
    + vpc_no = (known after apply) + zone = "KR-2" } ...中略
Plan: 13 to add, 0 to change, 0 to destroy.
Do you want to perform these actions?
 Terraform will perform the actions described above.
 Only 'yes' will be accepted to approve.
Enter a value: yes
ncloud_login_key.key_scn_02: Creating...
ncloud_vpc.vpc_scn_02: Creating...
ncloud_login_key.key_scn_02: Creation complete after 1s [id=tf-scn02]
ncloud_vpc.vpc_scn_02: Still creating... [10s elapsed]
ncloud_vpc.vpc_scn_02: Creation complete after 13s [id=2988]
ncloud_network_acl.network_acl_02_public: Creating...
ncloud_nat_gateway.nat_gateway_scn_02: Creating...
ncloud_network_acl.network_acl_02_private: Creating...
ncloud_network_acl.network_acl_02_private: Creation complete after 3s [id=4250]
ncloud_subnet.subnet_scn_02_private: Creating...
ncloud_network_acl.network_acl_02_public: Creation complete after 3s [id=4249]
ncloud_subnet.subnet_scn_02_public: Creating...
ncloud_nat_gateway.nat_gateway_scn_02: Still creating... [10s elapsed]
ncloud_nat_gateway.nat_gateway_scn_02: Creation complete after 13s [id=5648219]
ncloud_route.route_scn_02_nat: Creating...
ncloud_subnet.subnet_scn_02_private: Still creating... [10s elapsed]
ncloud_subnet.subnet_scn_02_public: Still creating... [10s elapsed]
ncloud_subnet.subnet_scn_02_private: Still creating... [20s elapsed]
ncloud_subnet.subnet_scn_02_public: Still creating... [20s elapsed]
ncloud_subnet.subnet_scn_02_private: Creation complete after 22s [id=5506]
ncloud_server.server_scn_02_private: Creating...
ncloud_subnet.subnet_scn_02_public: Creation complete after 22s [id=5507]
ncloud_server.server_scn_02_public: Creating...
ncloud_server.server_scn_02_private: Still creating... [10s elapsed]
ncloud_server.server_scn_02_public: Still creating... [10s elapsed]
...中略
ncloud_server.server_scn_02_public: Creation complete after 2m48s [id=5648223]
data.ncloud_root_password.scn_02_root_password: Reading...
ncloud_public_ip.public_ip_scn_02: Creating...
ncloud_network_acl_rule.network_acl_02_private: Creating...
data.ncloud_root_password.scn_02_root_password: Read complete after 0s [id=5648223]
ncloud_public_ip.public_ip_scn_02: Creation complete after 3s [id=5648227]
null_resource.ls-al: Creating...
null_resource.ls-al: Provisioning with 'remote-exec'...
null_resource.ls-al (remote-exec): Connecting to remote host via SSH...
null_resource.ls-al (remote-exec): Host: 110.165.17.xx
null_resource.ls-al (remote-exec): User: root null_resource.ls-al (remote-exec): Password: true
null_resource.ls-al (remote-exec): Private key: false null_resource.ls-al (remote-exec): Certificate: false
null_resource.ls-al (remote-exec): SSH Agent: false null_resource.ls-al (remote-exec): Checking Host Key: false
null_resource.ls-al (remote-exec): Connected!
null_resource.ls-al (remote-exec): total 24
null_resource.ls-al (remote-exec): dr-xr-x---. 4 root root 138 May 26 2020 .
null_resource.ls-al (remote-exec): dr-xr-xr-x. 18 root root 257 May 26 2020 ..
null_resource.ls-al (remote-exec): -rw-------. 1 root root 1441 May 26 2020 .bash_history
null_resource.ls-al (remote-exec): -rw-r--r--. 1 root root 18 Dec 29 2013 .bash_logout
null_resource.ls-al (remote-exec): -rw-r--r--. 1 root root 176 Dec 29 2013 .bash_profile
null_resource.ls-al (remote-exec): -rw-r--r--. 1 root root 176 Dec 29 2013 .bashrc
null_resource.ls-al (remote-exec): drwx------. 3 root root 17 May 26 2020 .cache
null_resource.ls-al (remote-exec): -rw-r--r--. 1 root root 100 Dec 29 2013 .cshrc
null_resource.ls-al (remote-exec): drwxr-----. 3 root root 19 May 26 2020 .pki
null_resource.ls-al (remote-exec): -rw-r--r--. 1 root root 129 Dec 29 2013 .tcshrc
null_resource.ls-al: Creation complete after 1s [id=8315713944255249232]
ncloud_network_acl_rule.network_acl_02_private: Still creating... [10s elapsed]
ncloud_network_acl_rule.network_acl_02_private: Still creating... [20s elapsed]
ncloud_network_acl_rule.network_acl_02_private: Creation complete after 25s [id=4250]
Apply complete! Resources: 14 added, 0 changed, 0 destroyed.
上のように最後にApply complete!が表示されれば、すべてのリソースの作成は完了します。

それからnull_resourceからSSHにアクセスしてみれば、ls -alもうまく実行されたことを確認できます。

 

では、リソースのうちサーバがうまく作成されたかどうかをコンソールで確認してみましょう。

f:id:navercloud:20210224192200p:plain

上のようにサーバ2台が正しく作成されたことが確認できます。

その他のリソースは、Terraformガイドを参考にして追加することができます。 

f:id:navercloud:20210108155858p:plain
今回の記事では、Terraformを用いてVPC環境でServerを作成し、サービスを提供する方法を説明いたしました。

VPCのような複雑な環境でTerraformを活用すれば、大規模なインフラ環境をより一層効率的に管理できます。

(* 全体のソースコードは、こちらをご参照ください。)

 

お役に立ちましたでしょうか? 次回の投稿でも有益な情報を提供いたします。

引き続きよろしくお願いします。

 

f:id:navercloud:20201209180753p:plain


 

建陽大学医療人工知能学科:高性能クラウドサーバインフラの活用

f:id:navercloud:20210224181029p:plain

一言話しかけるだけで曲を流してくれる人工知能スピーカー、
テキストを声に変えてくれる人工知能ダビング、
世界の囲碁チャンピオンに勝ったAIプログラムまで。
(アルファ碁ちゃん…元気でやってる…?)

私たちがこれまで見てきた、そして現在見ている人工知能の姿です。短ければ10年後、長ければ100年後の世界を大きく変える技術として挙げられる「人工知能(AI)」。医療分野のAI技術を研究し、地域社会と共に成長する建陽大学の医療人工知能学科を訪ねました。

NAVERクラウドの顧客でもある建陽大学の医療人工知能学科。どんな研究をして、地域社会の発展のためにどんな努力を傾けているのでしょうか。

建陽大学の医療人工知能学科を訪ねる。

[インタビュー] 建陽大学医療AI学科 キム・ウンシク教

 

Q1: 建陽大学について紹介してください。 

建陽大学は、「学生中心の教育」と「責任教育」を最高価値として実践する大学です。1991年に開学した建陽大学は「真の人徳を備えたクリエイティブな人材の育成」を建学理念とし、「一度教えたら最後まで責任を取る」という設立者のキム・ヒス博士の精神に基づき、「学生中心の教育」と「責任教育」を最高価値として実践してきました。

大学教育の競争力と質を高めるため、「産業連携教育活性化先導大学(PRIME)」、「教育の質の高い大学(ACE)」、「CK(university for Creative Korea)」事業など数多くの主要国策事業に取り組み、その結果、5年連続で就職率トップ5、韓国大学初となる世界3大デザインコンテストにて主要賞受賞、Apple Distinguished Schoolなどに選定されるといった成果を出してきました。

また、「生命工学先端研究団地 & 産学融合事業」により特性化キャンパスを運営し、実用的な「創意」・「融合」教育に基づいて優秀な人材を育成し、地域発展に必要な原動力を提供してきました。大田(テジョン)メディカルキャンパスは建陽大学病院と連携した大規模な研究センターの構築による先端医療融合技術研究団地であり、論山(ノンサン)創意融合キャンパスは国防及び軍事関連産業に基づいて地域産業を先導し、Active learningをリードする産学融合キャンパスとして成長・発展しつつあります。

 

Q2: 医療人工知能学科と産学協力団について紹介してください。

韓国教育部が選定した最先端学科として輝かしい医療人工知能学科は、AI技術を迅速に開発・商用化し、AI先導国として跳躍するための優秀人材の育成を目指しています。そのため、様々なAI技術を学んで自然言語処理、画像分析、自律走行、チャットボットなど多くの分野に応用できるAI開発能力を強化することに重点を置いています。特に、医科大学内の情報医学教室の医科大学院生は、大学病院の研究陣と共に医療AI分野のプロジェクトを進めており、共同研究を行っています。

建陽大学の産学協力団は2004年の立ち上げられて以来、建陽大学の2大キャンパス(大田メディカルキャンパス、論山創意融合キャンパス)の特性を活かす戦略を基に、融合型実用人材の育成に向けて現場中心の特色ある教育やクリエイティブな研究拡大に尽力してきました。優秀な研究人材を活用した技術開発や体系的な研究支援、技術の事業化に邁進して卓越した研究成果の拡大モデルを先導し、地域の企業に総合コンサルティングサービスを提供する専門メンターの役割を担い、企業の競争力確保をサポートしています。これにより大学の研究力強化や特性化に寄与するだけでなく、技術開発や事業化支援に至る多角的な支援を通じて地域社会の発展に大きく貢献しました。

 また、産学協力の体系化に向け舒川(ソチョン)、唐津(タンジン)、公州(コンジュ)など8か所に地域産学協力センターを運営し、自治体に合わせて産学協力を先導しており、産業別に特化した支援組織としてBIZ-HUBを運営しています。大学の起業教育と支援のための起業保育センターを運営しているほか、韓山(ハンサん)からむし織、忠清南道のブランド酒事業団など地域産業をサポートしています。また、製造・研究の基盤施設が十分整っていない中小企業を支援するための中小企業産学協力センターと共同活用設備センター、産業デザインセンター、技術事業化センターを運営しています。

 

Q3: NAVERクラウドとの協力も活発に行っているとのことですが、内容を簡単に紹介してください。

医療人工知能学科で授業を行うには、大容量データを処理できる高性能なサーバリソースが必要です。ここで必要なGPUサーバリソースに関連する技術支援をNAVERクラウドから提供していただいています。去年は新型コロナウイルスによる非対面授業の拡大で、2,000以上のオンライン講座に円滑に対応するため、LMS(受講管理システム)をNAVERクラウドプラットフォームベースで構築しました。変化に対して柔軟に対応できない既存の物理電算資源の代わりにクラウドを活用中というわけです。NAVERクラウドプラットフォームがLMSシステムの構築でインフラの役割を担ってくれました。

 

​Q4: NAVERクラウドを選択した理由とメリットについて教えてください。

多くの大学とのクラウドインフラ構築やコンサルティングをされた経験が大きく作用しました。トラフィック変化への対応のコツや状況別の所要費用など、大学の必要事項や疑問を正確に理解し、ソリューションを提示してくれました。また、NAVERクラウドは韓国国内にデータセンターがあるため、データの主権を守りながら研究を行うことができ、必要なインフラリソースを安全かつ迅速に利用できるところがメリットといえます。 アカデミック支援プログラムの「グリーンルーキー(Green Rookie)」プログラムも大学にとって非常に有益ですが、先日締結した業務協力(MOU)によって提携の特典を提供して頂いています。

 

Q5: 「グリーンルーキー(Green Rookie)」プログラムの特典は何ですか?

建陽大学の在学生と教職員に、NAVERクラウドプラットフォームサービスを無料で使用できるクレジット、技術資格証の受験料クーポン、クラウドコンピューティング関連のオンライン・オフライン教育プログラムが提供されます。特に建陽大学のメールアドレスさえ持っていれば、クレジットが支給されてクラウドインフラリソースを気軽に活用できますが、学生や教職員にとってこれ以上の特典はありません。

 

Q6: 昨年9月には医療人工知能学習モデル開発ハッカソン(Korea Health Datathon)を主管されましたが、結果はどうでしたか?

そうですね。昨年9月21日から5日間、NAVERクラウド主催、建陽大学病院と国立がんセンター、建陽大学医療人工知能学科の主管により、オンライン「第2回コリアヘルスデータソン(Korea Health Datathon)」が開催されました。韓国で初めて実際の医療データを活用して、疾病診断プログラムを開発するコンテストでした。この大会は、韓国知能情報社会振興院による「2020人工知能学習用データ構築事業」の成果として構築された学習用データの活用に向け、医療映像とコホートデータを活用して実際に実装できる人工知能学習モデルを企画・開発するために設けられました。

ソフトウェア開発者、大学生、サラリーマンなど様々な職種から全50チーム(160人余り)が本選に参加し、副鼻腔炎乳がん疾患をテーマに2つのグループに分かれて、AI技術を融合したモデル開発を行いました。副鼻腔炎では「ホンカムラ」チームが、乳がんでは「CNUCV」チームがデータソン大会で優勝しました。実際の患者の医療データとAIディープラーニング技法を活用して、疾病を見つけ出すプログラムを開発する大会であるだけに非常に有益で意味ある大会であったと、参加者から多くの好評をいただきました。

 

Q7: 今後の医療AI関連産業や研究方向について、建陽大学の展望をお聞かせください。

治療中心から予防中心への次世代医療環境のパラダイム変化を、既存の医療技術や工学技術で実現するには現実的な限界があります。そのため、「AIの応用」という新しいチャレンジを進めています。

医科大学の情報医学教室や大学病院の医療情報室、ヘルスケアデータサイエンスセンターなどの病院と協力関係にあるSELVAS AI Inc.、VUNO Inc.、Lunit Inc.など様々なAI会社と協力し、大学病院やAI関連産業体がテーマを提案できるシステムを構築しました。これにより大学病院や企業メンターが参加して、地域内における関連分野の研究所や企業との緊密な協力を通じてプロジェクトを進め、AI専門能力を備えた、医療分野に特化したAI人材を育成する計画です。

 

Q8: 産学協力という面からNAVERクラウドをはじめとする企業に期待する点は何でしょうか。

 人工知能技術が急速に発達し様々な分野に応用されている状況で、自然言語処理、自律走行、チャットボットなど一般人にとっても馴染み深い分野の技術も速いテンポで適用されつつあります。その中でも価値と専門性の高い医療分野で迅速な技術開発が行われ、新しい産業が出現しています。

ところが、韓国の人工知能人材は絶対的に不足しており、短期間でに人工知能専門能力を備えた、医療分野に特化した人工知能人材を養成するためには、医学・産業・学界の協力体制の構築が何よりも求められています。特に、医療分野に特化した開発環境構築のための医療人工知能Primitive serviceの開発が欠かせません。Cloud環境で医療人工知能に必要なPrimitive Serviceを活用すると、専攻実習の実務環境と同じ開発環境を経験できるからです。この過程でNAVERクラウドとの長期的な協力も期待しています。

 

インタビューを終えて NAVERクラウドチームの感想

昨年の「医療データハッカソン」イベント開催当時、NAVERクラウドも共同主催として一緒にPR・運営させていただいたことを覚えています。50ものチームが繰り広げた熱い競い合いに高性能クラウドGPUサーバを提供できて、非常にうれしかったです!

今回のインタビューを通じて「AI技術が医療に適用されれば、私たちの暮らしはもっと良くなるだろう」と漠然と想像していたことが現実のものになりつつあることを実感しました。地域内8か所の地域産学協力センターを運営し、医療・産業・学界が様々な協業を展開しているという点も印象深かったです。技術や産業の発展は、独りではなくみんなが一緒になって努力するからこそ成り立つということも改めて実感しました。

AI技術の研究、そして地域社会と共同成長に向けて、今日も尽力している建陽大学。たくさんのご声援を送ってください。医療人工学科と産学協力団との積極的な協力を期待しています。

 

 

f:id:navercloud:20201209181056p:plain

f:id:navercloud:20201209180753p:plain

 

韓国ソンナム市の新型コロナウイルス能動監視システムを、NAVERクラウドプラットフォームのCLOVA AiCallで構築しました。

f:id:navercloud:20210201145218p:plain

こんにちは。NAVERクラウドプラットフォームです。

新型コロナウイルスの対応としてCSに関する様々な対策が講じられていますが、韓国キョンギ道ソンナム市はNAVERクラウドプラットフォームの CLOVA AiCall商品を活用してAIケアコール相談サービスを構築しました。

CLOVA AiCallは、クラウドによる音声認識音声合成、チャットボット、テキスト分析といったサービスを提供するAI統合管理ソリューションツールです。小規模事業者から大手企業の顧客サポートまで幅広く使っていただける、電話による相談および予約のための対話型AIサービスです。24時間体制のお問い合わせ対応や予約、依頼された仕事の処理、リサーチ、販売、単なる電話の応対、顧客満足度調査のようなCS業務、そして診療予約から特殊な医療患者の管理まで医療、金融、公共など分野に特化されたサービスです。

 

 f:id:navercloud:20210201150421p:plain

ソンナム市のAIケアコールサービスは、「CLOVA AiCall」が能動監視対象者に体調確認や管理のための電話をかけます。一日に2回(午前9時と午後3時)、自動で電話をかけて発熱や呼吸器症状などをチェックし、その結果を保健所の担当者にEメールで共有することで、担当者が必要な措置が取れるようにします。能動監視対象者が電話に出なかった場合、10分後にさらに2回電話をかけてトータルで3回にわたり電話に出なければ担当者にEメールで知らせます。

f:id:navercloud:20210201145825p:plain
CLOVA AiCallのCall Centerのプロセス
包括的なカスタマーセンターの機能をサポートします。

既存の能動監視対象者に対するチェック方法は、保健所の担当者がいちいち電話をかけなければなりませんが、AIケアコールサービスではAIが人間の代わりにチェック業務をやってくれるだけに、保健所の仕事効率アップや迅速な対応に役立っています。また、みんなができるだけ避けたい対面業務を全面非対面にした点も注目に値します。テクノロジー新型コロナウイルスの影響下で厳しい状況にある人々を助ける良い例になると思います。 

皆様のビジネスのためのCLOVA AiCallサービスは、NAVERクラウドプラットフォームから提供されています。

詳しくは以下のリンクをご参考ください。

 

 f:id:navercloud:20210201150424p:plain

NAVERクラウドプラットフォームの優れたインフラとソリューションを活用して、簡単にビジネスを拡張してみてはいかがでしょうか。

ありがとうございました!

f:id:navercloud:20201209181056p:plain

f:id:navercloud:20201209180753p:plain


 

Retail & Insight: ー地域スーパーへO2Oプラットフォーム『トマトPOS』

f:id:navercloud:20210126210558p:plain

皆さん、こんにちは。NAVERクラウドプラットフォームです。

本日ご紹介する導入事例は、韓国唯一のB2C・B2B統合スーパーマーケットプラットフォーム専門企業のRetail & Insightです。

食品流通の経営コンサルティング及びシステム構築で韓国トップのRetail&Insightは、NAVERクラウドプラットフォームをどのように利用しているのか気になりますね。

インタビューから詳しく聞いてみましょう。

 

f:id:navercloud:20210108155858p:plain

1. 会社とサービスについて紹介してください。

Retail & Insight(以下RI)は、「韓国唯一のB2C・B2B統合スーパーマーケットプラットフォーム」専門企業であり、食品流通の経営コンサルティングとシステム構築分野で韓国トップの企業です。RIは、地域のスーパー業界が持つ高い成長潜在力に注目してきました。地域のスーパー業界が流通大手やオンライン流通に対抗できるITオンラインインフラを構築して、ハイパーコネクテッド・リテールプラットフォームHCRP(Hyper-Connected Retail Platform)を実現したいと思っています。

そのために、RIは業界で初めてオンラインとオフラインを分けない新しい決済方法を搭載した、スマートPOS「トマトPOS」を開発しました。これを地域のスーパーに無料で提供する予定です。これからも消費者や地域のスーパー、物流センター、メーカー、産地の皆が共存できるビジネスモデルを探し求め、地域のスーパーに最大限のサポートを行っていきます。

 

2. NAVERクラウドプラットフォームを選んだ理由は何ですか?

弊社がNAVERクラウドプラットフォームを選んだ理由は、とても明確です。全国各地のストアの店主とユーザーがメインターゲットとなる弊社サービスの特性上、初期の企画段階からクラウドを考えていました。NAVERクラウドプラットフォームは、韓国のソリューション会社として韓国国内にインフラと会員を幅広く備えており、NAVERのソリューションや事業の運営で成功しているため提携できる領域が多いと判断しました。特に、NAVERクラウドプラットフォームが地域のスーパーとの共存ビジネスに対して強い意志を見せたことが気に入りました。そのため、ビジネスの立ち上げ段階からNAVERクラウドプラットフォームと一緒にシステムを作っていこうと決めました。
IT関連トラブルが発生する場合、スピーディーに対応してもらえることも重要なポイントです。海外勢を利用すると問題が発生した時、どうしても対応に限界を感じますが、NAVERクラウドプラットフォームはよりスピーディーに問題を解決できるからです。また、費用的な面やPR、マーケティングに対するサポートもよかったです。

 

3. NAVERクラウドプラットフォームのどんなサービスを利用していますか?

利用しているサービスは次のとおりです。これからも継続して利用サービスを拡大したいと思っています。

4. NAVERクラウドプラットフォームの特徴またはメリットは何ですか?

NAVERクラウドプラットフォームは韓国人に馴染みのあるUI/UXになっているため、簡単に利用することができます速度や安定性といった面でも、弊社が期待していたレベルのパフォーマンスが出ています。何よりも、意見を提案したとき積極的かつポジティブに対応してもらえる点NAVERクラウドプラットフォームの最大メリットだと思います。

 

5. クラウドアーキテクチャをどのように構成しているのか教えてください。

弊社のサービスは、世界で初めて2万ヵ所のスーパーの6万個のPOSクラウドに載せられて運用されるプラットフォームです。それを勘案して次のようにクラウドアーキテクチャを構成しています。


 

6. 今後、NAVERクラウドプラットフォームを活用してどんなサービスを提供したいと思いますか?

弊社は現在O2O基盤のトマトPOSを地域のスーパーに提供していますが、今後は他のリテール分野やF&B業界にもサービスを拡大する計画があります。さらには、トマトPOSベースのオフライン決済やオンラインAPPサービスなどのB2Cから「トマトマーケット」という名前でスーパーのB2Bまでサービスを広げていく考えです。
また、弊社は各地のスーパーにてリアルタイムで取引される流通情報がたまった「ビッグデータ」を分析して、逆に地域のスーパーに役立つ競争力のあるインサイトを提供したいと思っています。弊社サービスとNAVERクラウドプラットフォームのインフラを融合することで、顧客に競争力のあるリテールインサイトを提供するシナジーを出せると思います。

 

f:id:navercloud:20210108155858p:plain

 

Retail & Insightは、NAVERクラウドプラットフォームの地域スーパーとの共存ビジネスに対する経験と理解をメリットとして挙げられました。 

ビジネスには、やはりNAVERクラウドプラットフォームが正解!

 

NAVERクラウドプラットフォームの優れたインフラとソリューションを活用して、簡単にビジネスを拡張してみてはいかがでしょうか。

 

ありがとうございました!

 

f:id:navercloud:20201209181056p:plain

f:id:navercloud:20201209180753p:plain

 

大学リモート教育のためのLMSニーズに増加にNAVERクラウドプラットフォームが対応しています。

f:id:navercloud:20210122171101p:plain

こんにちは。NAVERクラウドプラットフォームです。

新型コロナウイルスの拡大により、各大学はリモート教育に移行しており、LMSと呼ばれる学習情報システムに対するニーズが高まっています。NAVERクラウドプラットフォームはLMS専門エデュテック企業と提携して安定したクラウドサービスを提供するなど、学生たちがスムーズに受講できるよう努めています。現在、カチョン大学をはじめ、インチョン大学、ジョンナム大学など約40大学が利用しており、特にセジョン大学では、オンライン授業による急なトラフィック増加に有効に対応すべく、リモート教育システムを含む学事行政システム全体をNAVERクラウドプラットフォーム上から運営しています。

各LMS専門企業、そしてNAVERクラウドプラットフォームと提携している多くの大学では、様々なクラウドサービスを利用しています。サーバーストレージDBインフラセキュリティCDNAIメディアサービスなどを活用して、便利なリモート教育環境だけでなく、個人情報と教育コンテンツを安全に保護できる環境づくりに力を入れています。

では、約40大学の中からカチョン大学とセジョンサイバー大学の活用事例について見ていきましょう。

 

カチョン大学のクラウド導入による効果

f:id:navercloud:20210120191118p:plain

カチョン大学が導入したクラウド基盤LMSは、NAVERクラウドプラットフォームから提供される VOD Stationが取り入れられています。 VOD Station (Video on Demand Station)では映像ストリーミングを実現できるほか、映像全体を小サイズのパケットにパケット化して伝送するので安定した品質を提供します。

f:id:navercloud:20210120191244p:plain

カチョン大学が導入したクラウド基盤LMSは、NAVERクラウドプラットフォームから提供される VOD Stationが取り入れられています。 VOD Station (Video on Demand Station)では映像ストリーミングを実現できるほか、映像全体を小サイズのパケットにパケット化して伝送するので安定した品質を提供します。

そこにCDN(Contents Delivery Network)を連携して大量のトラフィックが発生しても、途切れることなく安定したオンライン受講が出来るようにしました。

 

セジョンサイバー大学のクラウド導入による効果

f:id:navercloud:20210120191201p:plain

セジョンサイバー大学も教育革新インフラづくりを掲げ、リモート教育システムを含む学事行政システムなどシステム全体をクラウド基盤にシフトしました。また、チャットボットや音声認識といったAIサービスを取り入れるなど、未来志向のシステムの設計に積極的です。

それを通じて、安定したコンテンツ提供やインフラ拡大が可能なシステム環境を確保できました。更には、コストカット、そしてウェブ基盤の運営ツールを活用した便利なインフラ全体の管理、柔軟なトラフィック対応も可能になりました。

f:id:navercloud:20210108155858p:plain

NAVERクラウドプラットフォームは、ユビオンやメディオピアテック等のエデュテック企業と技術提携をしています。また、 Green RookieというAcademic支援プログラムを通じて、NAVERクラウドプラットフォームを提携教育機関の学生や教職員に気軽に利用していただけるよう、割引クレジット提供やクラウド技術資格選考料支援、クラウド教育受講の機会提供といった特典を与えています。

また、NAVERクラウドプラットフォームは韓国教育学術情報院(KERIS)のe学習の場にもクラウドを提供しています。 KERISのオンライン始業の話は次回にご紹介しますので、楽しみにしてください!

 

ありがとうございました。 

 

f:id:navercloud:20201209181056p:plain

f:id:navercloud:20201209180753p:plain