EC2 Image Builderのメモ
ゴールデンイメージとは
事前に構成された環境をマシンイメージ化し、テンプレートとして使えるようにしたもの
これによりサービス提供の迅速化、内部共用利用による工数削減が見込める
ゴールデンイメージに含むものが増えるほど作成時間と頻度が問題になる
→イメージ作成のCI/CD化をする
ゴールデンイメージを定期的に作る課題
・CI/CD化には高いスキルを要する
・既存自動化ツールの維持運用が必要
・ソフトウェア更新の都度、手動で構築やテストが必要
・事前に問題検知ができず、本番運用後に問題が発生してしまう
☆EC2 Image Builderで課題解決する
EC2 Image Builderの機能
・OSイメージのビルド / カスタマイズ / デプロイを行う自動化されたパイプラインを作成
・セキュリティとコンプライアンスを満たした最新のイメージを作成
・AWS VM Import/Exportと組み合わせることで、AWS環境だけでなくオンプレミスで使用できる
・イメージを実稼働環境で使用する前に検証する仕組みの組み込み
・リビジョン管理と AWS アカウント間での自動化スクリプト、レシピ、および
イメージの共有
EC2 Image Builderの構成
・コンポーネント
ビルドコンポーネント
→ソフトウェアパッケージのダウンロード、インストール、構成の手順を定義するドキュメント
ソフトコンポーネント
→ソフトウェアパッケージで実行するテストを定義するドキュメント
コンポーネントは「Phases」と「Steps」で構成（YAMLで記述）
Phases
→Stepをまとめたもの
Steps
→個々の作業単位で実行するアクションを定義
・イメージレシピ
作成するイメージの設計書
ソースイメージと適用するビルドコンポーネント/テストコンポーネントを定義する
・イメージパイプライン
イメージ作成を自動化するための設定
レシピ、インフラの設定、配布設定、それを実行するトリガをパイプラインとして定義する
EC2 Image Builderの動作
①ソースイメージ選択
—↓↓自動化されたパイプライン—
②イメージにソフトウェアなどをインストール
→ ソフトウェア、ミドルウェア、AP、OSアップデート、パッチ
③AWS提供テストもしくは定義したテンプレートを実行しイメージをセキュアにする
→ セキュリティパッチ適用、暗号化、ポート閉塞等
④AWS提供テストもしくは定義したテストを実行する
⑤作成イメージを指定のAWSリージョン/アカウントに配布
パイプライン実行時の内部動作
①レシピで定義されたソースイメージとインスタンスタイプから EC2インスタンスが起動
② EC2インスタンスにレシピで指定したビルドコンポーネントがダウンロードされ、 EC2インスタンス上で実行
③EC2インスタンスが停止しAMIが作られ、その後インスタンスは terminate
④作成されたAMIからEC2インスタンスを起動
⑤EC2インスタンスにレシピで指定したテストコンポーネントがダウンロードされ、 EC2インスタンス上で実行される。
テスト後インスタンスはterminate
⑥上記の工程が正常に終了すると、 Output images の Status が「Available」になり完了
※実行制御はAWS Systems Manager Automationで実現されている
EC2 Image Builderの対応OSと出力フォーマット
・対応OS
Amazon Linux 2
Windows Server 2012、2016、2019、version 1909
Ubuntu Server 16、18
Red Hat Enterprise Linux (RHEL) 7、8
Cent OS 7、8（8はAMIを持ち込む必要あり）
SUSE Linux Enterprise Server (SLES) 15
・フォーマット
AMI
VHDX、VMDK、OVF
EC2 Image Builderの前提条件
レシピの内容に応じてIAMロールが必要
・最低限必要なIAMロールポリシーは以下
EC2InstanceProfileForImageBuilder （コンポーネントのビルドとテスト実行に必要なため）
AmazonSSMManagedInstanceCore （パイプラインは、SSM Automation により管理されるため）
レシピ内の記述によってそれぞれのIAMロール設定が必要です。
https://docs.aws.amazon.com/imagebuilder/latest/userguide/image-builder-service-linked-role.html
EC2 Image Builderはマネジメントコンソール、CLI、AWS Tools for SDK、CloudFomationで利用可能
EC2 Image Builderのログ
・出力先
S3（権限設置が必要）
CloudWatch Logs（デフォルトで有効）
EC2 Image Builderの料金
EC2 Image Builder自体は無償
イメージの作成、保存、共有するために利用したAWSリソース料金は課金
メモ用にAWS Blackbelt資料から情報を抜粋しています。
20200825 AWS Black Belt Online Seminar AWS EC2 Image Builder
AWS Batchのメモ
-バッチ処理とは
バッチコンピューティングはシュミレーション等、負荷の高い計算をスーパーコンピュータやクラスタ等で順次実行するような処理
→ゲノム解析、３DCGレンダリングやエンコード等のメディア処理
AWS Batchは上記のような大規模計算における「バッチ処理」を効率的に行うためのマネージドサービス
夜間や定時にジョブを実行するような定常業務におけるバッチ処理はAWS Batchでは満たせない
高価なスパコンを有効活用するために「ジョブ」をqueueingして順次処理する仕組みが考案された
・ユーザが投入したジョブを待ち行列に貯める（queueing）
・空いているコンピュータにジョブを割り当てて処理させる（dispatch）
-オンプレミスバッチコンピューティングの課題
・リソースが限られているので、ジョブが増えると待ち時間が長くなる
・物理コストが高い（そのものの費用や管理面）
-AWS上でバッチコンピューティングを作る利点
・複数ジョブを同時実行して処理時間を短縮できる
・クラウドなら必要に応じたスケールが可能なので、必要に応じた台数でクラスタ構成や上部スケジュールを組むことができ
ジョブが終了したらインスタンスを停止することでコストも抑えることが可能
・タスクに適したマシン構成が可能で無駄がない
-AWS Batchの概要
・ジョブはDockerコンテナイメージを元に作成し、自動でスケールするコンピューティング環境で実行
・インスタンスタイプやvCPU数、スポットインスタンス利用有無等を任意で指定
・コンテナを用意するだけでスケーラブルなバッチコンピューティング環境が使える
・Amazon CloudWatch、AWS Step Function、AWS CloudTrail等と連携可能
-AWS Batchより他AWSサービスが適しているケース
・コンテナ化が難しい
・既存のジョブスケジューラから移行が難しい
・1つのジョブが数秒で終わる
→AWS Step Functions ＋ LambdaやS3 batchを検討
・機械学習用とでモデル設計から推論エンドポイントまでやる
→sagemakerを検討
-AWS Batchの概念
・ジョブ定義（Job Defifitions）
→ジョブを作成する際のテンプレート
・ジョブ（Jobs）
→AWS Batchによって実行される作業単位
・ジョブキュー（Job Queues）
→投入されたジョブの待ち行列となる場所
・コンピューティング環境（Compute Environments）
→実際に計算を行うECSクラスター
・コンテナレジストリ
→Dockerコンテナイメージ置き場
・ストレージ（S3、EFS）
→永続化が必要なデータは外部ストレージへ
-AWS Batchの機能
・ジョブ状態の繊維
ジョブの状態変化をSNSに通知することが可能
ジョブを要求するリソースが、指定されたコンピューティング環境に含まれない場合は「Runnable」のまま停止するため注意
→おおきなvCPU/メモリを指定し、適合するインスタンスがコンピューティング環境にない
GPUを要求したがコンピューティング環境にGPUを含んだインスタンスがない
・配列ジョブとジョブ依存関係
配列ジョブ
→1回のジョブ投入で複数の小ジョブを作成
小ジョブは環境変数にて自身の配列IDを取得
配列IDで処理を分ける
ジョブ依存関係
→依存関係に指定したジョブが完了したら実行可能となる
・ジョブとコンピューティング環境Tips
ジョブ
→ジョブ試行回数/タイムアウトを指定する
コンピューティング環境
→マネージド型/アンマネージド型を指定可能だが通常はマネージド型を選択
インスタンスタンスタイプをファミリー単位で指定することでジョブ要求に対し最適なものが資料される
複数AZを指定することで耐障害性が上がる
最小vCPUを0とすることで使用しないときにはインスタンスが立ち上がらない設定になる
-AWS Batchのセキュリティ
・IAM PolicyによるAWS Batch API実行時の制約を設定
→コンテナ内にPOSIXユーザの制限
利用可能なコンテナイメージ/レジストリの制限
・ジョブ実行コンテナに対するIAM Role設定
→特定S3バケットへのアクセス等、必要最低限の権限を付与
・ジョブ投入等のAPIをCloudTrailに記録
-AWS Batchの活用方法
・ジョブの投入方法
→他のAWSサービスと連携したジョブ投入が可能
マネージメントコンソール/CLIからジョブ投入
S3ファイルアップロードトリガで、Lambdaファイルを処理するジョブを投入
CloudWatch Eventsで決められた時間にジョブ投入
・複雑なジョブワークフローの作成
→AWS Step Functionを使いAWS Batchのジョブ状態を管理
-事例
・HDDドライブヘッド設計 ピーク時7,000以上のコアを同時実行
→1ヶ月かかる処理を8時間で完了
・58,000コアを伸縮するシステム
→6週間かかるシュミレーションを10日で完了
・1,000万の化合物スクリーニングでピーク時90,000コアを同時処理
→39年分の計算処理を9時間で完了
メモ用にAWS Blackbelt資料から情報を抜粋しています。
20190911 AWS Black Belt Online Seminar AWS Batch
AWS 認定ソリューションアーキテクト – プロフェッショナルを受けてきた
2年前にこんなエントリを書きました。
2014年にSAアソシエイトを取得し、その2年後の2016年に再認定で更新し、時が経つのも早いものでまた2年経過し
更新の時期が来てしまいました。
ご丁寧にAWSからは失効しますよメールが数回に渡りきているので気付かず忘れてしまうということはありません。
今回もアソシエイト更新しようか上位のSAプロを受けるか迷いましたが、会社からは上位を取るよう指示が出ていたり、
バウチャーチケットが貰えて1回限定ですがSAプロの試験料が半額で受けられるということもあったので
チャレンジしてみました。
業務多忙ということもあり、あまり勉強時間が取れないのでGWの連休中に纏めて勉強する計画でいましたが、
連休は連休で家族サービスや別途やらなくてはいけない用事もあって、トータルで2,3時間やった程度となり
あとは平日の通勤電車内での学習しかしてないので、トータル5時間ちょっとで望むことになりました。
その少ない時間でやったのはあまり経験しないサービスを集中的に勉強しました。
月並みですがサービスのBlackBeltやドキュメント、よくある質問を眺めて理解していました。
EMRやKMS、CloudHSMこのあたりを重点的に見ました。おさらいという意味でIAMを再度見直しもしました。
それ以外のサービスは何もせずに日頃の業務知識でカバーする感じになりました。
試験は5/11に「銀座CBTS歌舞伎座テストセンター」で午後受験です。
cbt-s.com
お昼食べると眠くなるので、地下のセブンイレブンでレッドブルをキメて、アメを立て続けに2,3個食べて
試験に望むことにしました。
テスト機関がKryterion社からPSI社変わってから初めての受験となり前情報ではwebカメラ越しに監視されていたり、
web越しの試験官とは英語で対話しなくてはいけないなんて聞いていたので、んーどうしたもんかななんて思っていました。
blog.serverworks.co.jp
ところが当日受けた会場ではweb監視カメラ等なく、英語の必要性も全くありませんでした。
試験会場もキレイですし、この会場はオススメできます。
# 場所柄なのか救急車のサイレンが試験中に2回位聞こえてきました。。。
実際の試験ですが、、、、
アソシエイトに比べ複合的な問題になり長文問題になっていました。
サンプル問題ありますが、たしかにこんな感じの問題が多かった気がします。
http://media.amazonwebservices.com/jp/certification/AWS_certified_solutions_architect_professional_examsample0701_08_final.pdf
80問を170分で解かなきゃいけないので、時間配分が重要と言われていましたが、私は全力で全てを答えて
後から見直すスタイルを取りました。
個人的な感覚ですが、パッと答えられる問題が4割、よく読んで回答出来る問題が4割、何回か読み返して回答できる
問題が1.5割、問題の意味がわからない（誤訳？）のが0.5割といったところでしょうか。
100分程度で80問を解き終わり、その後は見直しをして10問くらい回答を替えました。
急いでいるために単純な引掛けにまんまとハマっている問題が幾つかあり、1時間以上見直しの時間があり
余裕をもって読み返えせたので、この方法は良かったのではないかと思っています。
お客様の要望（コスト or 可用性 or 耐久性 etc）があり、どのようなサービスを使って実現するか問われる
形式が大多数なので、正直後半部分をきちっと読んで理解すれば即回答が可能です。
選択肢は明らかに違うものが幾つか混ざっているので、これを弾くことが最初にやることで、そのあと
お客様が何を要求しているかを考えれば自ずと回答が見えてくるかと思います。
回答としておかしくないものが複数残りますが、最後はお客様が何を求めているのかが重要かと思います。
3時間弱の長丁場でしたが、無事に合格することが出来ました。
結果はあまり芳しくなく71%でした。もう少し高いかと思いましたがまだまだですね。
総合評点： 71%
トピックレベルスコアリング：
1.0 High Availability and Business Continuity: 66%
2.0 Costing: 75%
3.0 Deployment Management: 62%
4.0 Network Design: 75%
5.0 Data Storage: 50%
6.0 Security: 87%
7.0 Scalability & Elasticity: 76%
8.0 Cloud Migration & Hybrid Architecture: 71%
問題比率が出ているので逆算すると56/80問ってとこでしょうか。
まだまだ精進しないといけませんね。
【S3】オンプレ環境からセキュアにS3へアクセス
S3はインターネットからのアクセス経路しか持っていません。
VPCエンドポイントを利用するとVPCからS3までをAWS内で完結出来るため、パブリックなインターネットに触れないため比較的セキュリティが高いと言われています。
そこでエンタープライズ界隈ではしばしばVPCやDXを使ってインターネットを経由しないでオンプレミスから直接S3へアクセスしセキュア度を高めたいという話をよく聞きます。
VPCエンドポイントの名前解決さえできればアクセス出来ると思って、オンプレミスADのレプリカをAWS上に立てて名前解決させればいけそうなんて思い浮かびそうですが、これではできません。
これは仕様でドキュメントにも記載があります。
docs.aws.amazon.com
ーーー
エンドポイントの接続を、VPC から延長することはできません。VPN 接続、VPC ピア接続、AWS Direct Connect 接続、または VPC の ClassicLink 接続のもう一方の側のリソースは、エンドポイントを使用してエンドポイントサービスのリソースと通信することはできません。
ーーー
この仕様だと完全クローズ環境（インターネットに触れない）を実現したい場合は困りますね。
少しコストが掛かりますが、VPC内にEC2でproxyを立ててオンプレミスからはそのProxy経由でアクセスするようにすれば、完全クローズ環境でS3を利用することが可能かと思います。
【AWS】オンプレDNS（AD）にEC2を参加させる話
社内システムをAWS上に移設する際に必ず話題になるDNS（Active Directory 以下AD）をどうするかという問題。
DNSもRoute53へ移行して、ディレクトリ管理もSimple ADで、といきたいところだがそんな乗り気な会社はまずない。
影響の少ないサーバからお試しでAWS環境へ移行してみるのは当然のセオリーでオンプレ環境にDNS（AD）を残して
運用するいわゆるハイブリッド構成とした場合のDNS周りを少しだけ書いてみる。
よく聞かれるのがこれ。
AWS環境のサーバをオンプレミス環境のADに参加することは可能か？
AWS環境のサーバをオンプレミス環境のADに参加することはもちろん可能だけど、少々注意が必要になる。
VPCのデフォルト設定はEC2インスタンスが起動するときにDHCP経由でDNSサーバをVPC内で提供されている
AmazonDNSサーバ（Amazon Providid DNS）へ設定されてしまう。
オンプレミス環境のドメインに参加するためDNSサーバのIPアドレスを指定する必要がある。
【補足資料】
DHCP オプションセット - Amazon Virtual Private Cloud
VPC での DNS の使用 - Amazon Virtual Private Cloud
次がこれ。
AWS Directory Service（Simple AD or AD Connector）のどちらかが必要となるのか？
AWS Directory ServiceのBlackbelt資料の13ページにディレクトリタイプ（Simple AD and AD Connector）の説明がある。
これを見ると既存のディレクトリサービス（AD）に繋ぐためにはAD Connectorが必須のように捉えがちだがADの参加は可能。
AWSサービス（Workspaces、WorkDoccs等）をオンプレミスAD環境と連携したい場合にAD Connectorが必要になる。
【補足資料】
ネットワークでの AD Connector ディレクトリの準備 - Amazon WorkSpaces
それとまた別にこんな問題も。
この構成でS3をVPNエンドポイント経由で利用しようとするとAmazon Providid DNSを参照せずにアクセスできてしまう。
過去にAmazon Providid DNSを利用しないでVPNエンドポイントを利用することは非推奨と聞いたことを記憶しているので
確認したところ、やはり非推奨（利用を強く推奨という表現）とのこと。
オンプレミス環境のDNSサーバはフォワード先としてAmazon Providid DNSを利用することができないためAWS環境上に
DNSサーバを構築してそのDNSサーバをフォワード先にする必要ある。
非推奨の理由はおそらくVPCエンドポイントのIPアドレスが動的に変わるからだと想定している。
VPCエンドポイントを経由してS3へアクセスする場合、EC2からdescribe-prefix-listsコマンドで名前解決していて帰ってくる
IPアドレスも当然ながら一定ではない。
dev.classmethod.jp
Amazon Providid DNSはIP変更・追加が短い間に行われるので、こちらを参照していたほうが影響が少ないんじゃないかと思う。
オンプレミス環境のDNSに問い合わせた場合、キャッシュ保持等の影響で実際のVPCエンドポイントのIPアドレスが不一致を
起こしてアクセス出来ないことが可能性としては少ないかもしれないがあり得ることなんだと思う。
AWS 認定ソリューションアーキテクト – アソシエイト （再認定試験）を受けてきた
2年前にこんなエントリを書きました。
toatoshi.hatenablog.com
2年の月日が経過し、再認定試験の受講が必要となってしまいました。
5ヶ月前、3ヶ月前、1ヶ月前にkeyterionに登録してあるメールアドレスに再認定のお知らせをくれる親切なオペレーションなので
「忘れたー」ということにはならないですね。
ちなみにこのようなメールです。
ーーーーー
ーーーーー
あまり再認定に関してブログとか書かれているのを見かけなかったので軽く残しておこうかと思います。
概要
再認定を満たすには以下の2つどちらかが必要となるようです。
・アソシエイトレベルの再認定試験に合格する
・プロフェッショナルレベルの認定試験に合格する
アソシエイトレベル再認定の試験料は\8,100円で通常の半額で受けることができ、嬉しいことにこの時点でプロフェッショナルレベルの
認定試験を受ける場合も\16,200円で通常試験の半額で受けることができます。
再認定専用のサイトがこちら。
aws.amazon.com
試験内容の記載がないのですが、QAへのリンクをたどり確認します。
一番右の「AWS Recertification ( 再認定)」をポチッと。
試験内容に関するQAがありました。
Q: 再認定試験と通常の試験は何が違いますか?
A:再認定試験と通常の試験は設問が異なります。再認定試験の試験時間は 80 分です。再認定試験の出題範囲は、試験要覧で
明記されている内容と同じです。
設問が異なるとのことなので、2年経過しているのでアップデートの可能性もあるので通常試験のBlueprintを確認します。
中身を見てみると2年前の試験には無かったであろう「Trusted Adviser」、「CloudTrail」等が増えているようです。
これといって試験対策等はしなかったのですが、念のためBlackbeltを流し読みして試験に望みました。
QAサイトには通常試験と設問が異なると記載がありましたが、これが通常問題であっても全く違和感がない感じがします。
心なしか長文の問題が多く感じた記憶があります。
Blueprintに掲載されているAWSサービスが偏りなく見かけました。
日本語的に？なものも数問ありましたが、これはご愛嬌ですかね。
30分程度で回答を終え「提出」ボタンをクリック、、、、、
この瞬間は自信があってもドキドキしますね。
結果は無事合格。
業務的にAWS系の資格を保有していることが求められるシーンもあるため、受験料的にはプロフェッショナルにチャレンジ
したかったのですが手堅く再認定を取りました。
個人的な感想
再認定といえど通常試験を受けるものと思って受験されたほうがいいですね。
業務でAWSを使っているので改めて勉強の時間は取らず通勤時の資料閲覧くらいで済ませましたが、AWS業務ではない方や
ブランクがある方は通常試験を取得された時と同じような対策をされたほうが良いかと思います。
あと、東京の会場を選択されるご予定の方は早めに会場予約をされることをおすすめします。
私が予約しようと思った時は、どこの会場もほぼ空きがない状況でした。
5末が失効期限だったので4月2週に予約状況を確認したのですが、ゴールデンウィーク内の平日に2会場だけ空きがあり、
その次は5月3週まで空きがない状態、それを越すと次は6月1週まで受講できない状況でした。
AWS資格の人気があってのことか会場都合かはわかりませんが、ある程度余裕を持って予約しないと失効期限までに
受験できないなんてこともあるかも知れませんのでご注意を。
【勉強会】第19回八子クラウド座談会 vol2
前回の【勉強会】第19回八子クラウド座談会記事の続きです。
メモが多く情報を纏めるのに時間がかかってしまい今回のは、
第一部 インプットの前半部分2セッションを書きました。
「デジタル･ネイティブ世代と、クラウド･ネイティブ社会」
Agile Cat 鵜沢幹夫氏
ブログをやっている（ゲリラ翻訳ブログ）
AgileCat | Branding and Advertising Agency
1日1本で投稿。スポンサーへのレポート提出が生業
これで食べていける時代になっている。
メディアがデジタル化されていくため、メディア企業が自分たちをどうしていくべきかを
真剣に考えた結果を出している。
世代別に分けている。
世代ごとにどれだけメディアを使っているかを表す。
新聞読むことを止めた。新聞でなくても必要なニュースは拾える。
モバイルデバイスの浸食が大きく、さまざまなメディアをモバイル上で処理する。
アメリカの調査だが、日本でも同じと思える。
世代別分布図
右にシフト（年齢を重ねる）とメディアに対する接し方がドラスティックに変わる。
クラウドネイティブ社会
エンタープライズクラウド思いつくとこを上げた。
20年前にあった会社はMicrosoft、IBM、Cisco、VMWare、Oracleといったごく一部。
環境が整備されると一番デジタライゼーションしやすいビジネスはEコマースと思っている。
ひとつの裏付けとして、アマゾンができてAWS、アリババができてアリウム。
別のEコマースとしてスナップディール（インド）、フリップカート（自前DC作成でクラウドへ）、
がクラウドビジネスへ出ようとしている。
アメリカで起っていることががインドや中国で起きようとしている。
Facebookをエンタープライズカテゴリにいれた理由、、、
来年早々にFacebook At Workが出てくる。
エンタープライズ向けに丸ごとFacebookと同じものを提供（有償）
ロイヤルバンクオブスコットランド（イギリス銀行）が第一号。
企業内のコミュニケーションシステムをFacebookが肩代わりする時代。
→ソーシャルはクラウド
例えばyoutubeが企業内に閉じた教育コンテンツをその会社向けに提供するとかありえる
かもしれない。
デジタルネイティブ世代はこれらがある状態からITを触っていくことになる。
全てオンラインが当たり前といった時代。
そこに最適化したビジネスを考えていくことが大事。
2014年のエンタープライズ
売上場$16 billion。
Googleの広告の売り上げは$70 billion。
Androidは広告を売るためのOS。
FacebookはすぐにTimeWarnerを抜くと思っている。
Google、Facebookは広告配信、売り買いする場を持っている。Cloud Exchange。
Facebookグループのユーザー数を足すと述べ30億人
最近はアジアを追っかけている。
中国とインドの勢いが凄い。
中国のインターネット人口
モバイルが5.57億人
インターネット人口が6.49億人
モバイルがほぼインターネット人口を支えている。
インドに関しても今月インターネット人口が4億人を超える勢い。アメリカより大きい母数。
agilecatcloud.com
昨年夏頃に2019年に30億アカウントになると言われていて、信じられなかったが実際に
2015年現在で中国とインドを足すだけで10億位になっている。
アジアマーケットを対象にどのようなデジタライゼーションビジネスを展開していくかがポイント。
アリババが作った11月11日のSingles Day
アメリカのサイバーマンデーのような感じで、買い物の日という感じ。
昨年は1日で$9.3 billion、今年は$15 billion = 2兆円。
破壊と再生（Mckinseyレポート）
途上国との成長と都市化が一番のパワー
→デジタライゼーションを促進する力
2025年までに世界のGDPの半分以上が途上国に移っていく。
中国大連のGDPとスゥエーデンのGDPが同じ。ヨーロッパの1国が中国の都市と同じ。
技術の急速な進歩
→OSSの貢献
中国グレートファイアウォール（テクノロジーやビジネスが入りにくい）かったが
Linuxは入っていた。
中国のトップ企業はそれらを使ってトップレベルの技術力を誇る。
人口動態
→ロケーション観点、世代観点がある。
これを見ていかないとマーケットも見えない、人材採用の失敗する。
アジアのクラウドニュースを纏めているサイトが参考になる。
cloudnewsasia.com
「industry5.0 - Everything is Connected! Everything is Automated! -」
株式会社ABEJA
代表取締役CEO 岡田 陽介氏
ABEJAはAI（人工知能）のベンチャー企業
AIに関する日本のトップレベルの研究者を全員顧問に招聘している。
なので日本では絶対に負けないようなエンジンを持っている。
人工知能が最近になって急速にに進化しいていることが話題になっている。
その元が「Deep Learning」になっている。
Deep Learningとは、、、
2007年位から検索され始めていて2013年のあるタイミングから爆発的に検索数が伸びる。
Googleが猫の画像を人工知能に学習させたところ猫の画像を勝手に猫として認識し始めたという
ことがバズ化して話題になった。
人工知能はDARPAで産まれた。DARPAとは国防高等研究計画局でアメリカの軍事技術。
DARPAで何が産まれてきたかというと、「GPS」、「インターネット」、「ルンバ」とか。
軍事技術を持つ方達が自動的に画像収集するとかアナリティクスするとかが課題になって
おりそれを自動化するための技術として開発され始めた。
その技術をビジネスに応用したのがDeep Learning。
Deep Learning技術の過去と今。
昔は目、鼻、口等を1つ1つ切り離してそれを覚えさす作業（人手で）
データ量が集まらず制度も出ない。
Deep Learningだと全てお任せ。顔写真を100万枚とか1000万枚とか覚えさせると
勝手にコンピュータがニューロン形成してくれる。勝手に学習し始める。
Deep Learningはエラー率が圧倒的に下がった。
もともと第一次人工知能ブームの時はエラー率60%、第二次で20%台、Deep Learningになると
10%以下になった。
今の研究しているものだと5%位まで下げられた。
テクノロジカルイノベーションをビジネスにしていくとビジネスイノベーションになる。
インストアナリティクスを採用している。
インストアナリティクスとは？
POSレジ通過したお客様の購買情報は取得できているが、お客様の状況に合わせた在庫最適
従業員最適が全くできない現状。
データをきちっと取る。人工知能の顔認識を使って来場者の年齢性別が一瞬で分かるとか
映像を解析して人の流れとか滞在をを出すとか。
これらデータを活用してプレディクティブシュミレーション（未来予想）が出来る。
明日必要な在庫や必要従業員数といったものが高い精度で予想ができる。
ABEJA今後考えていること
町の最適化。
全く取れていなかったデータをたくさん取る。
ビルやストアのリアルスペースデータや、メディアに訪れたビジターデータ、店舗の周りの
天気や気温、ソーシャルでつぶやかれていることをABEJAのエンジンいれる。
そうすることで店舗最適が簡単に行える。
リアルな最適化が出来る。
