はじめに 本記事は、以下の記事の続きです。 本記事では、前回に続き、Systems Managerのオートメーションランブックを実行できるようにします。 オートメーションランブックを使うと、Systems Managerのマネージドインスタンスにセキュリティーパッチを適用したり、Windows Server AMIにWindows Updateを全自動で終わらせるなど、様々なタスクを実行することができます。 記事のカバー範囲 AWSが用意した既成のランブックだけでなく、ユーザーがカスタマイズしたランブックも実行できるようにします。 ランブックのカスタマイズ方法についてはカバー範囲外です。 オートメーションのロールを理解する オートメーションの実行時に利用するロールとポリシーの関係です。 オートメーションを利用できるようにする Automationというサービスに渡すサービスロールを作成します 私は「AutomationServiceRole」というストレートな名前のロールを作成しました。 下記の要件を満たす必要があります。 AWS管理ポリシー「AmazonSSMAutomationRole」が付与されていること。 AWS管理ポリシー「AmazonSSMManagedInstanceCore」を含むロールに対するPassRoleの許可が与えられていること。 AWS管理ポリシー「AmazonSSMManagedInstanceCore」を含むロールは、前回の記事で「Role_SSMManagedCore」という名前で作成済みです。 以下は「Role_SSMManagedCore」ロールをPassRoleできるようにするインラインポリシー「PassRole_SSMManagedCore」の定義です。 { "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": "iam:PassRole", "Resource": "arn:aws:iam::744822404890:role/Role_SSMManagedCore" } ] } IAMユーザーにオートメーションを実行できる権限を付与します 私のIAMユーザー「kiyoka」に「AutomationServiceRole」をPassRoleできる権限を追加しました。 追加したインラインポリシーは以下のものです。 JSONも引用します。 { "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": "iam:PassRole", "Resource": "arn:aws:iam::744822404890:role/AutomationServiceRole" } ] } オートメーションを実行してみる 準備が整いましたので、簡単なオートメーションドキュメント「AWS-StopEC2Instance」を実行してみます。 既に、稼働中のインスタンスがある前提です。 IAMユーザー「kiyoka」でAWSマネジメントコンソールにサインインします。 Systems Managerの「自動化」をたどります。（メニューだけ翻訳されて「自動化」というキーワードになっています。奇妙ですが我慢しましょう） 「オートメーションの実行」ボタンを押します。 オートメーションドキュメントから「AWS-StopEC2Instance」を選択します。 次へを押します。 稼働中のインスタンスを選択し、オートメーションを実行するためのロールを選択します。上記で作成した「AutomationSeriviceRole」を選択し、「実行」を押します。 オートメーションが実行され、各ステップの状態が表示されます。 実行完了です。 最後に ここまでの設定が終わっていれば、AWS提供のランブックドキュメントをコピーしてカスタムランブックを実行できる権限もあります。 カスタムランブックを作って、手作業を減らしてみてください。

本記事は、Craft Egg Advent Calendar 2021の12/1の記事です。 はじめに MySQLを運用していく中で、ALTER文を流したいタイミングがたまにあります。 しかしLockがかかって大変なことになるのでは？とおもい、ALTER文ながすことをためらうことばかりでした。 Amazon Aurora MySQL3(MySQL8.0互換）がリリースされたこともあり、最近のMySQLのALTER文の改善をみていこうとおもいます。 調査対象のAmazon Auroa(MySQL)のバージョン 以下の３つのバージョンです。 Engine version (a) 5.6.mysql_aurora.1.23.4 (b) 5.7.mysql_aurora.2.10.1 (c) 8.0.mysql_aurora.3.01.0 調査するALTER文(LockがかかりそうなDDL） 次の４つのパターンを調査します。 (1)　カラム追加 次のようのなSQLです。 alter table `テーブル名` add `カラム名` '型'; (2) インデックスの作成 次のようなSQLです。 CREATE INDEX `インデックス名` ON `テーブル名` (`カラム名`) ; (3) VARACHAR型のカラムサイズの伸長 次のようなSQLです。 ALTER TABLE `テーブル名` CHANGE COLUMN `カラム名` `カラム名` VARCHAR(6); (4) パーティションの追加 次のようなSQLです(RANGE PARTITIONを想定) ALTER TABLE `テーブル名` ADD PARTITION (PARTITION `パーティション名` VALUES LESS THAN (5000)) ; 選出理由 ALTER文を流そうと思った時にためらいそうなもののなかで、MySQLのバージョンがあがるにつれ、改善されたALTER文を選んでいます。 それぞれの期待する結果は、次の通りです。 MySQL5.6 MySQL5.7 MySQL8.0 (1)カラム追加 ○ ○ ○ (2)インデックスの作成 ○ ○ ○ (3)VARACHAR型のカラムサイズの伸長 × ○ ○ (4)パーティションの追加 × × ○ ※○はLockがかからないことを示します（Meta Data Lockをのぞく） 参考 ・MySQL5.6に関してのLock ・MySQL5.7に関してのLock ・MySQL8.0に関してのLock テスト対象のテーブルの準備 今回検証するにあたり、データの準備をしていきます。 公式ドキュメントのオンライン DDL 実験のためのスキーマ設定コード の手順にしたがってテーブルとデータを用意します。 せっかく検証するのであれば、データ量がおおいほうがいいよね、とおもい（後々の後悔しましたが） 上記のドキュメントを参考に big_table というテーブルに 122,486,784 レコード（約1億レコード）データをいれました。(mysqldumpの出力結果が 22GB ほどになりました・・・） big_table の show create table の出力は次のとおりです。 Create Table: CREATE TABLE `big_table` ( `TABLE_CATALOG` varchar(512) CHARACTER SET utf8 NOT NULL DEFAULT '', `TABLE_SCHEMA` varchar(64) CHARACTER SET utf8 NOT NULL DEFAULT '', `TABLE_NAME` varchar(64) CHARACTER SET utf8 NOT NULL DEFAULT '', `COLUMN_NAME` varchar(64) CHARACTER SET utf8 NOT NULL DEFAULT '', `ORDINAL_POSITION` bigint(21) unsigned NOT NULL DEFAULT '0', `COLUMN_DEFAULT` longtext CHARACTER SET utf8, `IS_NULLABLE` varchar(3) CHARACTER SET utf8 NOT NULL DEFAULT '', `DATA_TYPE` varchar(64) CHARACTER SET utf8 NOT NULL DEFAULT '', `CHARACTER_MAXIMUM_LENGTH` bigint(21) unsigned DEFAULT NULL, `CHARACTER_OCTET_LENGTH` bigint(21) unsigned DEFAULT NULL, `NUMERIC_PRECISION` bigint(21) unsigned DEFAULT NULL, `NUMERIC_SCALE` bigint(21) unsigned DEFAULT NULL, `DATETIME_PRECISION` bigint(21) unsigned DEFAULT NULL, `CHARACTER_SET_NAME` varchar(32) CHARACTER SET utf8 DEFAULT NULL, `COLLATION_NAME` varchar(32) CHARACTER SET utf8 DEFAULT NULL, `COLUMN_TYPE` longtext CHARACTER SET utf8 NOT NULL, `COLUMN_KEY` varchar(3) CHARACTER SET utf8 NOT NULL DEFAULT '', `EXTRA` varchar(30) CHARACTER SET utf8 NOT NULL DEFAULT '', `PRIVILEGES` varchar(80) CHARACTER SET utf8 NOT NULL DEFAULT '', `COLUMN_COMMENT` varchar(1024) CHARACTER SET utf8 NOT NULL DEFAULT '', `id` bigint(21) unsigned NOT NULL AUTO_INCREMENT, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1 実際に検証 それでは、データの準備もできたので、実際にLockの有無を検証していきます。 データ量がおおくなってしまったので、検証につかうインスタンスは、 db.r5.xlarge を使用しています。 また、Lockがかかっているか、いないかをわかりやすくするために、INSERT文を１秒毎にbig_tableに対してながしていきます。 (1)　カラム追加 の検証 実際に流すのは次のSQLです。 alter table big_table add addcolumn int ,LOCK=NONE, ALGORITHM=INPLACE; (a) 5.6.mysql_aurora.1.23.4 INSERT文をながしながら、カラム追加を実行している様子です。 （左：INSERT文、右：カラム追加） こちらLockかかることなく実行できました。 (b) 5.7.mysql_aurora.2.10.1 INSERT文をながしながら、カラム追加を実行している様子です。 （左：INSERT文、右：カラム追加） こちらLockかかることなく実行できました。 (c) 8.0.mysql_aurora.3.01.0 INSERT文をながしながら、カラム追加を実行している様子です。 （左：INSERT文、右：カラム追加） こちらLockかかることなく実行できました。 (2) インデックスの作成 の検証 実際に流すのは次のSQLです。 CREATE INDEX idx_1 ON big_table (`ORDINAL_POSITION`) ; (a) 5.6.mysql_aurora.1.23.4 INSERT文をながしながら、インデックスの作成をしている様子です。 （左：INSERT文、右：インデックスの作成） こちらLockかかることなく実行できました。 (b) 5.7.mysql_aurora.2.10.1 INSERT文をながしながら、インデックスの作成をしている様子です。 （左：INSERT文、右：インデックスの作成） こちらLockかかることなく実行できました。 (c) 8.0.mysql_aurora.3.01.0 INSERT文をながしながら、インデックスの作成をしている様子です。 （左：INSERT文、右：インデックスの作成） こちらLockかかることなく実行できました。 (3) VARACHAR型のカラムサイズの伸長 の検証 実際に流すのは次のSQLです。 alter table big_table modify `TABLE_SCHEMA` varchar(128); (a) 5.6.mysql_aurora.1.23.4 INSERT文をながしながら、VARCHAR型のカラムサイズの伸長をしている様子です。 （左：INSERT文、右：VARCHAR型のカラムサイズの伸長） 想定通り、Lockがかかりました(左のINSERT文がとまっている）。 (b) 5.7.mysql_aurora.2.10.1 INSERT文をながしながら、VARCHAR型のカラムサイズの伸長をしている様子です。 （左：INSERT文、右：VARCHAR型のカラムサイズの伸長） ！なんと、想定外に、Lockがかかってしまいました。 理由は後述します。(※１) (c) 8.0.mysql_aurora.3.01.0 INSERT文をながしながら、VARCHAR型のカラムサイズの伸長をしている様子です。 （左：INSERT文、右：VARCHAR型のカラムサイズの伸長） ！なんと、想定外に、Lockがかかってしまいました。 こちらも理由は後述します。(※１) ※１ Lockがかかってしまった理由 正確な理由はわからなかったのですが、Lockがかからず実行できるケースもありました。 そもそもまず、SQLの見直しからです。 ALTER TABLE small_table CHANGE COLUMN `IS_NULLABLE` `IS_NULLABLE` VARCHAR(6), ALGORITHM=INPLACE, LOCK=NONE; こちらのSQLはLockがかからず実行できました（テーブル名に注目）。 実は、テーブルのレコード件数が少ないときは（4000レコード）、Lockがかららず実行できたのですが、 今回の検証用のテーブル(1億レコード）では、エラーになってしまいました。 マニュアルをよむとVARCHARの伸長には、制約があることがわかります。 レコード件数が増えたことによって、制約にひっかかっていそうです。 (4) パーティションの追加　の検証 実際に流すのは次のSQLです。 事前に次のSQLを実行してパーティションを作成します。 ALTER TABLE `small_table` PARTITION BY RANGE (`id`) ( PARTITION p1000 VALUES LESS THAN (1000), PARTITION p4000 VALUES LESS THAN (4000) ) ; その後、次のパーティションの追加のSQLを実行して検証します。 ALTER TABLE small_table LOCK=NONE, ALGORITHM=INPLACE, ADD PARTITION (PARTITION p5000 VALUES LESS THAN (5000)) ; (a) 5.6.mysql_aurora.1.23.4 INSERT文をながしながら、パーティションを追加している様子です。 （左：INSERT文、右：パーテシションの追加） 構文エラーとなり、SQLが実行できませんでした（想定通り）。 (b) 5.7.mysql_aurora.2.10.1 INSERT文をながしながら、パーティションを追加している様子です。 （左：INSERT文、右：パーテシションの追加） こちらも、サポートしていないLockというエラーがでて、実行できませんでした（想定通り）。 (c) 8.0.mysql_aurora.3.01.0 INSERT文をながしながら、パーティションを追加している様子です。 （左：INSERT文、右：パーテシションの追加） 無事、構文エラーになることもなく、Lockもかかることもなく、実行できました。 補足 検証前は、マニュアルを読んで、次のSQL（パーティションの作成）がLockなしに実行できるものだと思っていました。 ALTER TABLE `small_table` ALGORITHM=INPLACE PARTITION BY RANGE (`id`) ( PARTITION p10 VALUES LESS THAN (10), PARTITION pmax VALUES LESS THAN MAXVALUE ) ; しかし、サポートされているのは、あくまで ADD PARTITION のため、上記SQLは構文エラーとなります。 まとめ 実際に検証した結果をまとめると次のようになります。 MySQL5.6 MySQL5.7 MySQL8.0 (1)カラム追加 ○ ○ ○ (2)インデックスの作成 ○ ○ ○ (3)VARACHAR型のカラムサイズの伸長 × △ △ (4)パーティションの追加 × × ○ △：実行できる場合もある（制約によって実行に失敗する） おわりに 昔からのMySQLの先入観で、基本的にALTER文はLockがかかってしまうとおもっていました。 しかし今回あらためて、マニュアルを見て、LockのかからないALTER文が増えていることに気づきました。 実際に実行してみると、Lockは、かからず、MySQLに対する先入観が覆されました。 また、新しいバージョンでLockがかからないALTER文は増えているのは検証を進める中でわかったのですが、 制約があるために、使えそうな機会は狭そうというのが正直なところです。 今回の検証が皆様の役に立てればと思います。 明日は@ishiguro_takuyaの記事です！

概要 下記の続きとなります。 過信 そもそも、NLBがどのIPでヘルスチェックしているかを俺は理解していなかった。 ヘルスチェックをするIPはCloudFrontのIPアドレスではなくNLBの所属するVPC内で払いだされたIPアドレス。 NLBの先のインスタンスではCFのIPアドレスとVPCのCIDR(AWS公式はVPCのCIDRを登録するのが推奨っぽい)をセキュリティグループで許可してあげなければいけない。 ターゲットセキュリティグループ 罠 上記の設定をしたのち、ヘルスチェックも通りアプリアクセスも正常にいけた。 しかし、主題であるアクセスをCloudFrontからのみに制限するということが実現できておらずNLB直でもアクセスできてしまうことが発覚しました。 アプリアクセス的にはCloudFrontのIPしか許可していないのにNLB直が何故かイケてしまう状況。。 構成図的には下記のような状態だった。 設定値を眺めているとNLBのターゲットグループでクライアント IP の保存というのがあり、 これが無効になっていたのが原因だった。 クライアント IP の保存 クライアントIPを保持していると信じていたのにそうではなくNLBのIPアドレスでアクセスしていたので ヘルスチェック用のSGで通ってしまっていた状態だった。 終わりに どういった違いで設定が変わるかを覚えておくことが重要な気がします。 インスタンス ID でターゲットを指定する場合 →すべての受信トラフィックのクライアント IP が保持される。 IP アドレスでターゲットを指定する場合 →ターゲットグループプロトコルが TCP または TLS の場合、クライアント IP 保存はデフォルトで無効です。 →ターゲットグループプロトコルが UDP および TCP_UDP の場合、クライアント IP 保存はデフォルトで有効です。 今回の場合、IPアドレスでターゲットを指定しており、ターゲットプロトコルがTCPであった為、 IP アドレスでターゲットを指定する場合の1つ目に該当していたようです。

概要 ・CloudFrontの後段にELBがいるような構成になっていてCloudFrontではAWS WAFでDDos等防いでいるが、 　ELB及びEC2へは直接アクセスできてしまうのでブロックしたいパターン。 ・ALBであればカスタムヘッダ/WAFで制御することも可能だが、今回はNLBということで後段のSGインバウンドを動的に対応させることに。 公式ブログを参考にしていくことに。　 https://aws.amazon.com/jp/blogs/security/how-to-automatically-update-your-security-groups-for-amazon-cloudfront-and-aws-waf-by-using-aws-lambda/ ※大まかな手順等は上記公式ブログに記載の為今回は省きます。 構成 構成の流れとしては以下 ①初回は公式ブログにあるテストをし、現在のIP RangeからLambdaの中でCloudFrontのGLOBAL/REGIONALのIPを抽出しSGに反映する。 ②それ以降は、IP Rangeが更新されるたびに公式から公開されているSNSをトリガーにLambdaが動作してSGを更新してくれる。 問題① 公式ブログで参照先になっているPythonコードを試したところ、このissueに挙がってる問題に直面し上手くいかなかったので上記エラーを解決しているものを使用することにしました。 問題② セキュリティグループのルール数に上限(デフォルト50)があり、GLOBALのIPを追加するセキュリティグループのルールが上限を超えてしまう問題があります。 セキュリティグループのNameタグで対象を選択しているので同じNameタグのセキュリティグループの数を増やすorセキュリティグループのルール数の上限緩和をする必要があります。 セキュリティグループのルール数の上限緩和も制約があるので申請する場合は確認したほうが良いと思います。 https://aws.amazon.com/jp/premiumsupport/knowledge-center/increase-security-group-rule-limit/ 注意点 当たり前だろ、と思われるかと思いますが構築中にあるLambdaのトリガー設定をするCLIはSNSがあるリージョンで実行しなければならないのでexport AWS_DEFAULT_REGION=us-east-1等してから実行しないと上手くいきません。 今回自分はTerraformで構築したのですが、その際にもalias等使用してトリガーの設定をしないと上手くいかないと公式にも書いてあるので要注意です。 https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/sns_topic_subscription まとめ ・セキュリティグループの上限緩和をしたりセキュリティグループ名を変更したい事もあるのでその場合はやはりコードの改良が必要かと思いました。

概要 ・CloudFrontの後段にELBがいるような構成になっていてCloudFrontではAWS WAFでDDos等防いでいるが、 　ELB及びEC2へは直接アクセスできてしまうのでブロックしたいパターン。 ・ALBであればカスタムヘッダ/WAFで制御することも可能だが、今回はNLBということで後段のSGインバウンドを動的に対応させることに。 公式ブログを参考にしていくことに。　 https://aws.amazon.com/jp/blogs/security/how-to-automatically-update-your-security-groups-for-amazon-cloudfront-and-aws-waf-by-using-aws-lambda/ ※大まかな手順等は上記公式ブログに記載の為今回は省きます。 構成 構成の流れとしては以下 ①初回は公式ブログにあるテストをし、現在のIP RangeからLambdaの中でCloudFrontのGLOBAL/REGIONALのIPを抽出しSGに反映する。 ②それ以降は、IP Rangeが更新されるたびに公式から公開されているSNSをトリガーにLambdaが動作してSGを更新してくれる。 問題① 公式ブログで参照先になっているPythonコードを試したところ、このissueに挙がってる問題に直面し上手くいかなかったので上記エラーを解決しているものを使用することにしました。 問題② セキュリティグループのルール数に上限(デフォルト50)があり、GLOBALのIPを追加するセキュリティグループのルールが上限を超えてしまう問題があります。 セキュリティグループのNameタグで対象を選択しているので同じNameタグのセキュリティグループの数を増やすorセキュリティグループのルール数の上限緩和をする必要があります。 セキュリティグループのルール数の上限緩和も制約があるので申請する場合は確認したほうが良いと思います。 https://aws.amazon.com/jp/premiumsupport/knowledge-center/increase-security-group-rule-limit/ 注意点 当たり前だろ、と思われるかと思いますが構築中にあるLambdaのトリガー設定をするCLIはSNSがあるリージョンで実行しなければならないのでexport AWS_DEFAULT_REGION=us-east-1等してから実行しないと上手くいきません。 今回自分はTerraformで構築したのですが、その際にもalias等使用してトリガーの設定をしないと上手くいかないと公式にも書いてあるので要注意です。 https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/sns_topic_subscription 続編

これはなに？ aws cliを使って、バケットに保存されている最新のオブジェクトを取得したかったのでそのコマンドのメモです。 コマンド --prefixでどのディレクトリから探すかを指定できる。 Contents[?LastModified >= `2021-11-24T03:21`]でどの時間より後かを指定している。 コマンド aws s3api list-objects --bucket my-bucket-name --prefix Directry/ --query 'Contents[?LastModified >= `2021-11-24T03:21`]' | jq -r 'sort_by(.LastModified) | reverse | .[0] | .Key' おまけ 出力されたオブジェクト名をそのまま用いて、オブジェクトの詳細を取得できる。 コマンド aws s3api head-object --bucket my-bucket-name --key ↑のコマンドの出力で得られたオブジェクト名 出力結果 { "AcceptRanges": "bytes", "Expiration": "expiry-date=\"Mon, 25 Nov 2024 00:00:00 GMT\", rule-id=\"xxxxxxxxxxxx\"", "LastModified": "2021-11-25T08:48:23+00:00", "ContentLength": 105171, "ETag": "\"xxxxxxxxxxxxxxxxx\"", "ContentEncoding": "gzip", "ContentType": "application/json", "ServerSideEncryption": "AES256", "Metadata": {} }

背景 AWSのEC２にデプロイするためにmysqlに入ろうとしたがパスワードが間違っていて入れず、パスワードを思い出すこともできなかったので再設定しました。 /etc/my.cnf vimで/etc/my.cnfを開き、[mysqld]の下にskip-grant-tablesと書きます。 /etc/my.snf [myaqld] skip-grant-tables mysqlを再起動 mysqlを再起動します。 sudo service mysqld restart mysqlに接続 mysql -u root mysqlに接続し、以下のように入力することでDB内のテーブルを再読み込みします。 mysql> flush privileges; 新しいパスワードを設定！ alter user 'root@localhost' identified by '新しいパスワード' 新しいパスワードを設定したらDBから退出し、 mysql> quit vim /etc/my.cnf内のskpip-grant-tablesを削除します。(あるいはコメントアウト) そしてmysqlを再起動します。 ついに接続！ mysql -u root -p を入力し、先ほど作成したパスワードで接続できれば、パスワードの再設定は成功です！

はじめに：本稿のターゲット データサイエンティストを目指す若手エンジニアや学生向けに投稿しました いまもっとも熱い職種の一つとなっているデータサイエンティスト。 その影響もあって大学生や若手の社会人でもその道を目指す人が増えています。 私は現在インターンの採用面談をしていますが、その工程の中で、 ◎データサイエンティストはどのような仕事なのか解像度がまだ低い ◎実社会で求められているスキルと目指す側の方向性に乖離が起きている というようなことを感じましたので一度ここで振り返っておこうと思います。 データサイエンティストに求められる条件は数学だけなのか？ 以下はデータサイエンティストに求められる素養を端的に表現した図になります。 ご覧の通り。求められる素養は　プログラミング力、ビジネス力、数学力の３つが条件となっています。 データサイエンティストを目指している学生はほぼ皆さん数学の勉強はしっかりされています。 積極的にコンペに参加したり、そういう研究に参加したり。それ自体はとても素晴らしいことです。今後も是非継続してもらいたいものです。 しかし、気になっているのはそれの一点突破になっている人が多いことです。 私は数学ができます。なのでデータサイエンティストになりたいです。という論理構成で来たら皆さんはどう思いますか？将来は相関、因果、傾向と対策を分析したい人がイケてない論理構成している。この時点で解像度が低く、採用意欲はわきませんね。 データサイエンティストになるには数学”も”素養がないといけない。 では数学は当然としてなぜプログラミング力やビジネス力が必要なのか説明していきます。 プログラミング力が必要とされる理由①データの整形 データさえあれば分析できるという誤解 統計学上必要なデータの母数があれば、分析できると思っている方が多く、むしろそう思うほうがデフォルトだと思うのですが、ここが最初の乖離、解像度の低い原因となります。 ではなぜ分析できないのか？ 例　住所記入の場合 ◎東京都新宿区西新宿2丁目8-1 ◎東京都新宿区西新宿2-8-1 ◎東京都新宿区西新宿２－８－１ ◎東京都新宿区西新宿二ー八－一 上の住所は全て東京都庁の住所になります。同じものを表現しています。そして全て正しいです。 なので住所としての機能は十分で、郵便を送る際にはどのフォーマットでもちゃんと届くでしょう。 全角数字は基本的に文字として認識されますが、郵便配達の方が読んでわかれば良いので数字だろうと文字だろうと機能します。 しかし解析や分析を行う場合、対象データにバラバラのフォーマットが混在していたら統一性がないので分析できません。 このように住所として機能することを前提として作られた住所録はそれを満たせば十分なので、分析性を考慮していません。世の中にあるデータは分析性を考慮されているもののほうが圧倒的に少ないでしょう。このような場合、分析するためにはフォーマットを統一する必要があります。 データを分析にも適した形に変更するという作業が必要になります。 どのフォーマットに統一するのが良いか（アーキテクト思考等）、いかに手早く作業（プログラミング等）するのか、今後はどういう運用にするか（運用構築等）を考えるためには技術的な考察や作業が必要となります。 大学で使用するデータはすでに整形されているものが多いと思われるので、この作業認識が希薄になりやすいと思います。分析する前にやっかいな仕事があるという認識を明示的に持ったほうが良いでしょう。 プログラミング力が必要な理由②大量のデータを分析するために必要な環境構築 データが分析できるようになったあとは・・・ こちらは広義な意味で技術力の話になります。 データを分析できる形に整形が終わったら次はデータを分析します。 何十万、何百万、ときには何千万件、それ以上の膨大なデータ量になるかもしれません。 以前はその処理に耐えられるスペックの実環境を用意できる会社でしか巨大なデータ分析はできませんでしたが、現在はAWS等を始めとしたクラウド技術を使用することにより障壁が低くなりました。 しかしクラウド環境とはいえ、高スペックの環境を構築するとコストは高くなります。 重要なデータを扱う場合（個人情報など）、セキュリティの概念も当然必要となります。 その条件はプロジェクトにより異なると思いますが、 適切な予算で、セキュアで、有益な情報を生み出す環境を構築する必要があります。実際のクラウド環境構築作業は別担当者で行ってもらうかもしれませんが、プログラムを実施する上での開発環境の構築という視点が必要になってきます。 ビジネス力が必要な理由①数字を使って読み解き、お金の概念を含めて説明する力 研究とビジネスの違いを意識しよう 当然ですがビジネスは学術ではありません。お金を稼ぐ優先度は高いです。 研究としての学術的な正しさを追い求めるわけではないので区別が必要です。 研究にお金がかかるのでスポンサーを集める等の逆引き的な商業行為も現実的には必要とわかっていますがビジネスと学術は基本的は別なものです。 学術的に価値がある研究が必ず儲かるわけではありませんし、本質的にはその必要もないです。 ですがビジネスにおいて、自分がある問題の相関や因果を見つけ、傾向と対策を仮説立て実施したい場合、その説明を数学の専門家ではない人達に説明して納得して貰う必要があります。そこには収益の概念も必要ですし、コストの概念も必要です。その概念がない限り、ビジネスとしては成立しません。 いかに良い仮説であっても、実行できなければ一生仮説のままです。それを検証する、現実に落とし込むためにはコミュケーション能力も含めて戦略性などのビジネスの概念や要因が必要になります。 授業で習ったことと違う場合もあるでしょうし、直接的には習っていないことも多々出てくるでしょう。それが当たり前で、それでも問題解決のために注力し続けることが大切です。それが実学としてインターンを経験する魅力でもあると思っています。 ビジネス力が必要な理由②数字で語るのは当たり前、それはすでにビジネスの常識である ビジネスの世界語は数字である 実社会で求められられていることと目指している人の乖離の原因の一つがこのポイントだと思います。 学生の皆さんはデータサイエンティストは解析、分析をする人、というイメージを持っている人が多いです。それもある意味正しいですが、それだけをやっている人はごく一部だと思います。 そのようなデータの解析がメインになるような業界、会社は絞られていると思われ ◎すでに膨大なデータがある ◎そのデータが分析する環境が整っている（BIツールなど導入済み） というような条件がすでに揃っている会社だと思います。 BIツールはビジネスインテリジェンスと呼ばれ、ビジネス上で必要な気づきを数学的思考やビジネスのテンプレートに則り見える化を手伝うシステムだと思ってください。 Tableuなど高度なBIツールになれば専門性のある数学の知識も必要になってきます。それを使って分析をメインで行っているデータサイエンティストの方もいるでしょう。その場合は数学の専門性が重要になってくると思いますので、数学の専門性を持っている学部（理工学部、数学科）などのほうが強いのではないでしょうか？そしてそのような募集はデータサイエンティストの中の少数あると思われます。 自分がそこを目指して数学のコンペや勉強をしている人は問題ありません。そのまま続けましょう。しかし、ただデータサイエンティストがそんなイメージだから、というだけの方は注意が必要です。 現在の実社会においてある程度のビジネススキルを持つ人であれば、簡単（場合によってはある程度の）な分析や解析は行います。目標や計画を数字で語る上で必須のスキルであるからです。 データが準備できており、ExcelのPivot機能でその説明に十分な表現ができるならそれでOKです。 言い換えればそれ以外の場合、それ以上の専門性（プログラミング、数学、ビジネス）が必要な場合でデータサイエンティストの出番となるわけです。将来的に自分の強みをどこにおくのか、そのイメージは持っておいたほうが良いでしょう。 レース場でタイムを競うのか、ボコボコの道をタフに走り抜けるか 同じレースだけど質が違う ごく一部のデータ解析をメインに行える人たちのイメージがF１のような整備されたレース場をいかに早く走り切るかのレースをしているのと同様です。道路もマシンもスタッフもお金や時間を使って整っている。あとはそれらを最大化するためにどうするかが腕の見せどころ、といった感じです。 その他の大多数の人はオフロードレースでボコボコの道を走り抜ける技術や気構えが必要となります。どこに穴が空いているかわからない、ひょっとしたらマシンが壊れるかもわからない、それでも応急処置をしつつ走り抜ける。そのような整地作業を経て次のフェーズに進むというイメージです。 現状の実社会ではオフロードのようなボコボコのデータを整形し、環境を整えたくてもなかなかうまく行かず、ようやく分析し、解析して正しいか考察する、それを繰り返すといったような泥臭い作業が多いです。決して華やかな仕事ばかりではありません。 こちらもまたインターンを実施する場合、どのような仕事が多いのかイメージのすり合わせを行ったほうがミスマッチが防げると考えています。 まとめ 最後に要点をまとめておきます。 ◎データサイエンティストには数学力、プログラミング力、ビジネス力が必要 ◎データを分析する作業の前にはデータが分析できるようにする作業が必要 ◎学術とビジネスは目指すゴールが違う ◎自分の強みはどこになるか考えよう。 ◎データサイエンティストは泥臭い作業も多い（能力としてそこが求められている） 以上のポイントを再度認識しておくようにしてください。 面接の準備として・・・ 学生の段階で数学、技術、ビジネスのすべての素養が十分にある、という人はいません。 もしいたらインターンをする必要はないでしょう。 なので、面接の準備として（これはインターンの面接に限らずですが） 自分の得意な分野、課題のある分野を自分自身で把握し、将来進みたい方向をざっくりでいいので決めておきましょう。もちろん後で進路変更しても良いでしょう。思ったのと違ったのであれば修正することも全然OKだと思います。 ですが自分の希望とミスマッチを起こさないためにその準備自体はしっかりとしておきましょう。 インターン募集中です 株式会社EXIDEAではデータサイエンティストのインターン生を募集しております。 この文面を読んで我こそは！という方はぜひ以下のURLから応募してください。 皆様の応募をお待ちしております。 Wantedlyから・・・ https://www.wantedly.com/projects/782385 ０１インターンから・・・ https://01intern.com/job/2745.html 補足 データサイエンティストに求められるスキルチェックリスト https://www.datascientist.or.jp/news/release20211119/

はじめに：本稿のターゲット データサイエンティストを目指す若手エンジニアや学生向けに投稿しました いまもっとも熱い職種の一つとなっているデータサイエンティスト。 その影響もあって大学生や若手の社会人でもその道を目指す人が増えています。 私は現在インターンの採用面談をしていますが、その工程の中で、 ◎データサイエンティストはどのような仕事なのか解像度がまだ低い ◎実社会で求められているスキルと目指す側の方向性に乖離が起きている というようなことを感じましたので一度ここで振り返っておこうと思います。 データサイエンティストに求められる条件は数学だけなのか？ 以下はデータサイエンティストに求められる素養を端的に表現した図になります。 ご覧の通り。求められる素養は　プログラミング力、ビジネス力、数学力の３つが条件となっています。 データサイエンティストを目指している学生はほぼ皆さん数学の勉強はしっかりされています。 積極的にコンペに参加したり、そういう研究に参加したり。それ自体はとても素晴らしいことです。今後も是非継続してもらいたいものです。 しかし、気になっているのはそれの一点突破になっている人が多いことです。 私は数学ができます。なのでデータサイエンティストになりたいです。という論理構成で来たら皆さんはどう思いますか？将来は相関、因果、傾向と対策を分析したい人がイケてない論理構成している。この時点で解像度が低く、採用意欲はわきませんね。 データサイエンティストになるには数学”も”素養がないといけない。 では数学は当然としてなぜプログラミング力やビジネス力が必要なのか説明していきます。 プログラミング力が必要とされる理由①データの整形 データさえあれば分析できるという誤解 統計学上必要なデータの母数があれば、分析できると思っている方が多く、むしろそう思うほうがデフォルトだと思うのですが、ここが最初の乖離、解像度の低い原因となります。 ではなぜ分析できないのか？ 例　住所記入の場合 ◎東京都新宿区西新宿2丁目8-1 ◎東京都新宿区西新宿2-8-1 ◎東京都新宿区西新宿２－８－１ ◎東京都新宿区西新宿二ー八－一 上の住所は全て東京都庁の住所になります。同じものを表現しています。そして全て正しいです。 なので住所としての機能は十分で、郵便を送る際にはどのフォーマットでもちゃんと届くでしょう。 全角数字は基本的に文字として認識されますが、郵便配達の方が読んでわかれば良いので数字だろうと文字だろうと機能します。 しかし解析や分析を行う場合、対象データにバラバラのフォーマットが混在していたら統一性がないので分析できません。 このように住所として機能することを前提として作られた住所録はそれを満たせば十分なので、分析性を考慮していません。世の中にあるデータは分析性を考慮されているもののほうが圧倒的に少ないでしょう。このような場合、分析するためにはフォーマットを統一する必要があります。 データを分析にも適した形に変更するという作業が必要になります。 どのフォーマットに統一するのが良いか（アーキテクト思考等）、いかに手早く作業（プログラミング等）するのか、今後はどういう運用にするか（運用構築等）を考えるためには技術的な考察や作業が必要となります。 大学で使用するデータはすでに整形されているものが多いと思われるので、この作業認識が希薄になりやすいと思います。分析する前にやっかいな仕事があるという認識を明示的に持ったほうが良いでしょう。 プログラミング力が必要な理由②大量のデータを分析するために必要な環境構築 データが分析できるようになったあとは・・・ こちらは広義な意味で技術力の話になります。 データを分析できる形に整形が終わったら次はデータを分析します。 何十万、何百万、ときには何千万件、それ以上の膨大なデータ量になるかもしれません。 以前はその処理に耐えられるスペックの実環境を用意できる会社でしか巨大なデータ分析はできませんでしたが、現在はAWS等を始めとしたクラウド技術を使用することにより障壁が低くなりました。 しかしクラウド環境とはいえ、高スペックの環境を構築するとコストは高くなります。 重要なデータを扱う場合（個人情報など）、セキュリティの概念も当然必要となります。 その条件はプロジェクトにより異なると思いますが、 適切な予算で、セキュアで、有益な情報を生み出す環境を構築する必要があります。実際のクラウド環境構築作業は別担当者で行ってもらうかもしれませんが、プログラムを実施する上での開発環境の構築という視点が必要になってきます。 ビジネス力が必要な理由①数字を使って読み解き、お金の概念を含めて説明する力 研究とビジネスの違いを意識しよう 当然ですがビジネスは学術ではありません。お金を稼ぐ優先度は高いです。 研究としての学術的な正しさを追い求めるわけではないので区別が必要です。 研究にお金がかかるのでスポンサーを集める等の逆引き的な商業行為も現実的には必要とわかっていますがビジネスと学術は基本的は別なものです。 学術的に価値がある研究が必ず儲かるわけではありませんし、本質的にはその必要もないです。 ですがビジネスにおいて、自分がある問題の相関や因果を見つけ、傾向と対策を仮説立て実施したい場合、その説明を数学の専門家ではない人達に説明して納得して貰う必要があります。そこには収益の概念も必要ですし、コストの概念も必要です。その概念がない限り、ビジネスとしては成立しません。 いかに良い仮説であっても、実行できなければ一生仮説のままです。それを検証する、現実に落とし込むためにはコミュケーション能力も含めて戦略性などのビジネスの概念や要因が必要になります。 授業で習ったことと違う場合もあるでしょうし、直接的には習っていないことも多々出てくるでしょう。それが当たり前で、それでも問題解決のために注力し続けることが大切です。それが実学としてインターンを経験する魅力でもあると思っています。 ビジネス力が必要な理由②数字で語るのは当たり前、それはすでにビジネスの常識である ビジネスの世界語は数字である 実社会で求められられていることと目指している人の乖離の原因の一つがこのポイントだと思います。 学生の皆さんはデータサイエンティストは解析、分析をする人、というイメージを持っている人が多いです。それもある意味正しいですが、それだけをやっている人はごく一部だと思います。 そのようなデータの解析がメインになるような業界、会社は絞られていると思われ ◎すでに膨大なデータがある ◎そのデータが分析する環境が整っている（BIツールなど導入済み） というような条件がすでに揃っている会社だと思います。 BIツールはビジネスインテリジェンスと呼ばれ、ビジネス上で必要な気づきを数学的思考やビジネスのテンプレートに則り見える化を手伝うシステムだと思ってください。 Tableuなど高度なBIツールになれば専門性のある数学の知識も必要になってきます。それを使って分析をメインで行っているデータサイエンティストの方もいるでしょう。その場合は数学の専門性が重要になってくると思いますので、数学の専門性を持っている学部（理工学部、数学科）などのほうが強いのではないでしょうか？そしてそのような募集はデータサイエンティストの中の少数あると思われます。 自分がそこを目指して数学のコンペや勉強をしている人は問題ありません。そのまま続けましょう。しかし、ただデータサイエンティストがそんなイメージだから、というだけの方は注意が必要です。 現在の実社会においてある程度のビジネススキルを持つ人であれば、簡単（場合によってはある程度の）な分析や解析は行います。目標や計画を数字で語る上で必須のスキルであるからです。 データが準備できており、ExcelのPivot機能でその説明に十分な表現ができるならそれでOKです。 言い換えればそれ以外の場合、それ以上の専門性（プログラミング、数学、ビジネス）が必要な場合でデータサイエンティストの出番となるわけです。将来的に自分の強みをどこにおくのか、そのイメージは持っておいたほうが良いでしょう。 レース場でタイムを競うのか、ボコボコの道をタフに走り抜けるか 同じレースだけど質が違う ごく一部のデータ解析をメインに行える人たちのイメージがF１のような整備されたレース場をいかに早く走り切るかのレースをしているのと同様です。道路もマシンもスタッフもお金や時間を使って整っている。あとはそれらを最大化するためにどうするかが腕の見せどころ、といった感じです。 その他の大多数の人はオフロードレースでボコボコの道を走り抜ける技術や気構えが必要となります。どこに穴が空いているかわからない、ひょっとしたらマシンが壊れるかもわからない、それでも応急処置をしつつ走り抜ける。そのような整地作業を経て次のフェーズに進むというイメージです。 現状の実社会ではオフロードのようなボコボコのデータを整形し、環境を整えたくてもなかなかうまく行かず、ようやく分析し、解析して正しいか考察する、それを繰り返すといったような泥臭い作業が多いです。決して華やかな仕事ばかりではありません。 こちらもまたインターンを実施する場合、どのような仕事が多いのかイメージのすり合わせを行ったほうがミスマッチが防げると考えています。 まとめ 最後に要点をまとめておきます。 ◎データサイエンティストには数学力、プログラミング力、ビジネス力が必要 ◎データを分析する作業の前にはデータが分析できるようにする作業が必要 ◎学術とビジネスは目指すゴールが違う ◎自分の強みはどこになるか考えよう。 ◎データサイエンティストは泥臭い作業も多い（能力としてそこが求められている） 以上のポイントを再度認識しておくようにしてください。 面接の準備として・・・ 学生の段階で数学、技術、ビジネスのすべての素養が十分にある、という人はいません。 もしいたらインターンをする必要はないでしょう。 なので、面接の準備として（これはインターンの面接に限らずですが） 自分の得意な分野、課題のある分野を自分自身で把握し、将来進みたい方向をざっくりでいいので決めておきましょう。もちろん後で進路変更しても良いでしょう。思ったのと違ったのであれば修正することも全然OKだと思います。 ですが自分の希望とミスマッチを起こさないためにその準備自体はしっかりとしておきましょう。 インターン募集中です 株式会社EXIDEAではデータサイエンティストのインターン生を募集しております。 この文面を読んで我こそは！という方はぜひ以下のURLから応募してください。 皆様の応募をお待ちしております。 Wantedlyから・・・ https://www.wantedly.com/projects/782385 ０１インターンから・・・ https://01intern.com/job/2745.html 補足 データサイエンティストに求められるスキルチェックリスト https://www.datascientist.or.jp/news/release20211119/

はじめに：本稿のターゲット データサイエンティストを目指す若手エンジニアや学生向けに投稿しました いまもっとも熱い職種の一つとなっているデータサイエンティスト。 その影響もあって大学生や若手の社会人でもその道を目指す人が増えています。 私は現在インターンの採用面談をしていますが、その工程の中で、 ◎データサイエンティストはどのような仕事なのか解像度がまだ低い ◎実社会で求められているスキルと目指す側の方向性に乖離が起きている というようなことを感じましたので一度ここで振り返っておこうと思います。 データサイエンティストに求められる条件は数学だけなのか？ 以下はデータサイエンティストに求められる素養を端的に表現した図になります。 ご覧の通り。求められる素養は　プログラミング力、ビジネス力、数学力の３つが条件となっています。 データサイエンティストを目指している学生はほぼ皆さん数学の勉強はしっかりされています。 積極的にコンペに参加したり、そういう研究に参加したり。それ自体はとても素晴らしいことです。今後も是非継続してもらいたいものです。 しかし、気になっているのはそれの一点突破になっている人が多いことです。 私は数学ができます。なのでデータサイエンティストになりたいです。という論理構成で来たら皆さんはどう思いますか？将来は相関、因果、傾向と対策を分析したい人がイケてない論理構成している。この時点で解像度が低く、採用意欲はわきませんね。 データサイエンティストになるには数学”も”素養がないといけない。 では数学は当然としてなぜプログラミング力やビジネス力が必要なのか説明していきます。 プログラミング力が必要とされる理由①データの整形 データさえあれば分析できるという誤解 統計学上必要なデータの母数があれば、分析できると思っている方が多く、むしろそう思うほうがデフォルトだと思うのですが、ここが最初の乖離、解像度の低い原因となります。 ではなぜ分析できないのか？ 例　住所記入の場合 ◎東京都新宿区西新宿2丁目8-1 ◎東京都新宿区西新宿2-8-1 ◎東京都新宿区西新宿２－８－１ ◎東京都新宿区西新宿二ー八－一 上の住所は全て東京都庁の住所になります。同じものを表現しています。そして全て正しいです。 なので住所としての機能は十分で、郵便を送る際にはどのフォーマットでもちゃんと届くでしょう。 全角数字は基本的に文字として認識されますが、郵便配達の方が読んでわかれば良いので数字だろうと文字だろうと機能します。 しかし解析や分析を行う場合、対象データにバラバラのフォーマットが混在していたら統一性がないので分析できません。 このように住所として機能することを前提として作られた住所録はそれを満たせば十分なので、分析性を考慮していません。世の中にあるデータは分析性を考慮されているもののほうが圧倒的に少ないでしょう。このような場合、分析するためにはフォーマットを統一する必要があります。 データを分析にも適した形に変更するという作業が必要になります。 どのフォーマットに統一するのが良いか（アーキテクト思考等）、いかに手早く作業（プログラミング等）するのか、今後はどういう運用にするか（運用構築等）を考えるためには技術的な考察や作業が必要となります。 大学で使用するデータはすでに整形されているものが多いと思われるので、この作業認識が希薄になりやすいと思います。分析する前にやっかいな仕事があるという認識を明示的に持ったほうが良いでしょう。 プログラミング力が必要な理由②大量のデータを分析するために必要な環境構築 データが分析できるようになったあとは・・・ こちらは広義な意味で技術力の話になります。 データを分析できる形に整形が終わったら次はデータを分析します。 何十万、何百万、ときには何千万件、それ以上の膨大なデータ量になるかもしれません。 以前はその処理に耐えられるスペックの実環境を用意できる会社でしか巨大なデータ分析はできませんでしたが、現在はAWS等を始めとしたクラウド技術を使用することにより障壁が低くなりました。 しかしクラウド環境とはいえ、高スペックの環境を構築するとコストは高くなります。 重要なデータを扱う場合（個人情報など）、セキュリティの概念も当然必要となります。 その条件はプロジェクトにより異なると思いますが、 適切な予算で、セキュアで、有益な情報を生み出す環境を構築する必要があります。実際のクラウド環境構築作業は別担当者で行ってもらうかもしれませんが、プログラムを実施する上での開発環境の構築という視点が必要になってきます。 ビジネス力が必要な理由①数字を使って読み解き、お金の概念を含めて説明する力 研究とビジネスの違いを意識しよう 当然ですがビジネスは学術ではありません。お金を稼ぐ優先度は高いです。 研究としての学術的な正しさを追い求めるわけではないので区別が必要です。 研究にお金がかかるのでスポンサーを集める等の逆引き的な商業行為も現実的には必要とわかっていますがビジネスと学術は基本的は別なものです。 学術的に価値がある研究が必ず儲かるわけではありませんし、本質的にはその必要もないです。 ですがビジネスにおいて、自分がある問題の相関や因果を見つけ、傾向と対策を仮説立て実施したい場合、その説明を数学の専門家ではない人達に説明して納得して貰う必要があります。そこには収益の概念も必要ですし、コストの概念も必要です。その概念がない限り、ビジネスとしては成立しません。 いかに良い仮説であっても、実行できなければ一生仮説のままです。それを検証する、現実に落とし込むためにはコミュケーション能力も含めて戦略性などのビジネスの概念や要因が必要になります。 授業で習ったことと違う場合もあるでしょうし、直接的には習っていないことも多々出てくるでしょう。それが当たり前で、それでも問題解決のために注力し続けることが大切です。それが実学としてインターンを経験する魅力でもあると思っています。 ビジネス力が必要な理由②数字で語るのは当たり前、それはすでにビジネスの常識である ビジネスの世界語は数字である 実社会で求められられていることと目指している人の乖離の原因の一つがこのポイントだと思います。 学生の皆さんはデータサイエンティストは解析、分析をする人、というイメージを持っている人が多いです。それもある意味正しいですが、それだけをやっている人はごく一部だと思います。 そのようなデータの解析がメインになるような業界、会社は絞られていると思われ ◎すでに膨大なデータがある ◎そのデータが分析する環境が整っている（BIツールなど導入済み） というような条件がすでに揃っている会社だと思います。 BIツールはビジネスインテリジェンスと呼ばれ、ビジネス上で必要な気づきを数学的思考やビジネスのテンプレートに則り見える化を手伝うシステムだと思ってください。 Tableuなど高度なBIツールになれば専門性のある数学の知識も必要になってきます。それを使って分析をメインで行っているデータサイエンティストの方もいるでしょう。その場合は数学の専門性が重要になってくると思いますので、数学の専門性を持っている学部（理工学部、数学科）などのほうが強いのではないでしょうか？そしてそのような募集はデータサイエンティストの中の少数あると思われます。 自分がそこを目指して数学のコンペや勉強をしている人は問題ありません。そのまま続けましょう。しかし、ただデータサイエンティストがそんなイメージだから、というだけの方は注意が必要です。 現在の実社会においてある程度のビジネススキルを持つ人であれば、簡単（場合によってはある程度の）な分析や解析は行います。目標や計画を数字で語る上で必須のスキルであるからです。 データが準備できており、ExcelのPivot機能でその説明に十分な表現ができるならそれでOKです。 言い換えればそれ以外の場合、それ以上の専門性（プログラミング、数学、ビジネス）が必要な場合でデータサイエンティストの出番となるわけです。将来的に自分の強みをどこにおくのか、そのイメージは持っておいたほうが良いでしょう。 レース場でタイムを競うのか、ボコボコの道をタフに走り抜けるか 同じレースだけど質が違う ごく一部のデータ解析をメインに行える人たちのイメージがF１のような整備されたレース場をいかに早く走り切るかのレースをしているのと同様です。道路もマシンもスタッフもお金や時間を使って整っている。あとはそれらを最大化するためにどうするかが腕の見せどころ、といった感じです。 その他の大多数の人はオフロードレースでボコボコの道を走り抜ける技術や気構えが必要となります。どこに穴が空いているかわからない、ひょっとしたらマシンが壊れるかもわからない、それでも応急処置をしつつ走り抜ける。そのような整地作業を経て次のフェーズに進むというイメージです。 現状の実社会ではオフロードのようなボコボコのデータを整形し、環境を整えたくてもなかなかうまく行かず、ようやく分析し、解析して正しいか考察する、それを繰り返すといったような泥臭い作業が多いです。決して華やかな仕事ばかりではありません。 こちらもまたインターンを実施する場合、どのような仕事が多いのかイメージのすり合わせを行ったほうがミスマッチが防げると考えています。 まとめ 最後に要点をまとめておきます。 ◎データサイエンティストには数学力、プログラミング力、ビジネス力が必要 ◎データを分析する作業の前にはデータが分析できるようにする作業が必要 ◎学術とビジネスは目指すゴールが違う ◎自分の強みはどこになるか考えよう。 ◎データサイエンティストは泥臭い作業も多い（能力としてそこが求められている） 以上のポイントを再度認識しておくようにしてください。 面接の準備として・・・ 学生の段階で数学、技術、ビジネスのすべての素養が十分にある、という人はいません。 もしいたらインターンをする必要はないでしょう。 なので、面接の準備として（これはインターンの面接に限らずですが） 自分の得意な分野、課題のある分野を自分自身で把握し、将来進みたい方向をざっくりでいいので決めておきましょう。もちろん後で進路変更しても良いでしょう。思ったのと違ったのであれば修正することも全然OKだと思います。 ですが自分の希望とミスマッチを起こさないためにその準備自体はしっかりとしておきましょう。 インターン募集中です 株式会社EXIDEAではデータサイエンティストのインターン生を募集しております。 この文面を読んで我こそは！という方はぜひ以下のURLから応募してください。 皆様の応募をお待ちしております。 Wantedlyから・・・ https://www.wantedly.com/projects/782385 ０１インターンから・・・ https://01intern.com/job/2745.html 補足 データサイエンティストに求められるスキルチェックリスト https://www.datascientist.or.jp/news/release20211119/

CloudFront のオリジン、ビヘイビアの設定のプロトコルの欄について。 オリジンの設定 CloudFront からオリジンへのアクセスプロトコルを指定する。 選択肢は以下の3つ。 - HTTP のみ - HTTPS のみ - マッチビューワー 例えば、HTTPを選択するとクライアントから HTTPS でアクセスが来ても CloudFront からオリジンへのアクセスは HTTP を使用する。 また、マッチビューワーを使用してクライアントのプロトコルに応じた切り替えも可能。 ビヘイビアの設定 ビューワープロトコルポリシー クライアントからのリクエストを受け付けるプロトコルを指定する。 選択肢は以下の3つ。 - HTTP と HTTPS の両方からのリクエストを受け付ける - HTTP を　HTTPS にリダイレクトする - HTTPS のリクエストのみ受け付ける 許可された HTTP メソッド 受け付ける HTTP メソッドを選択できる。 (僕はここが [GET, HEAD] だったために PUT を受け付けず、ブラウザからWordPressが表示できない、という失敗をした。) 参考資料

Node.jsのプログラムをLambdaにアップロードするときに、node_modulesの容量が大きすぎてエラーになることがあります。 それを回避するために、公式側でLambdaレイヤーにnode_modulesを登録することができるようになっているので、今回はその方法を紹介します。 前提 Node.jsをインストール済み npm installの実行など、Node.jsに関する基礎知識がある Lambdaに関する基礎知識がある 手順 公式ドキュメントの Lambda レイヤーの作成と共有 を参考に進めていきます。 1. nodejsフォルダを作成する 「ただフォルダを作成するだけ」 ではありますが、1点注意点があります。 フォルダ名は必ず「nodejs」で作成します。 2. nodejsフォルダでモジュールをインストールする nodejsフォルダ内で、必要なモジュールをインストールします。 npm initは不要で、インストールのみでOKです。 今回はrequestモジュールだけインストールしておきます。 3. nodejsフォルダをzip化する zip化しましょう。 4. Lambdaレイヤーの作成 Lambdaコンソールからレイヤーを作成します。 僕のアカウントではnode_modulesという名前で作成済みです。 zipファイルをアップロードしますが、10MB以上の場合はS3を使用することが推奨されています。 ランタイムは必要なNodeのバージョンを選択してください。 5. 関数にレイヤーを追加 対象の関数コンソールからレイヤーを追加します。 これで登録と追加ができたので作業完了です。 モジュールを追加したい場合は、ローカルでnpm installしてからバージョンを作成することでバージョンアップできます。 まとめ 今回はLambdaレイヤーにnode_modulesを登録する方法を紹介しました。 基本的な内容でしたが、参考になれば幸いです。 参考資料 Lambda レイヤーの作成と共有

VMworld 2021 Japan に参加したのでVMware Cloud on AWS 関連のセッションまとめます.。2021/11/25-26でライブ配信されていて、2021年末までオンデマンド視聴/資料ダウンロードも可能です。 1. そもそもVMworldって？ VMware社の年次カンファレンスです。他にもいろんな会社(例えばApple社)も自社の大型イベントで新製品や新機能の発表しているかと思います。今年USでは10/5-7にオンラインで開催されました。日本でも同イベント(VMworld 2021 Japan)は11/25-26でライブ配信されます。(再掲) そのほかは過去記事もご参照ください。 2. VMworld 2021 Japan セッションの見どころ（VMware Cloud on AWS 関連） AWSもスポンサーということで、いくつもVMware Cloud on AWS関連のセッションを公開しています。日本のお客様事例や調査会社のレポートも閲覧・ダウンロード可能となっていて参考になります。 VMwareでVMware Cloud on AWSを担当されている方がブログでもお勧めセッションをピックアップされています。 3. 関連記事

はじめに 災害が発生した場合、ビジネスを継続するために、必要になるサービス 『AWS Elastic Disaster Recovery (DRS)』についてAWSがブログを投稿されていたので このブログでさらに読みやすくなるように解説していきたいと思います。 想定される考慮事項 定期的なデータバックアップ以上のことが必要 ビジネスの目標復旧時間 (RTO) を満たす完全なリカバリ データの処理に使用されるインフラストラクチャ、オペレーティングシステム、アプリケーション、および構成も含める ランサムウェアの脅威の増大に伴い、完全なポイントインタイムリカバリを実行できる環境の必要性 ランサムウェア攻撃の影響を受けた企業では、手動のバックアップからデータを復元するだけでは不十分です。 過去の対策での問題点 これまで、企業は物理的災害対策 (DR) インフラストラクチャを個別にプロビジョニングすることを選択していました。 要求されるまで、アイドル状態のままであるハードウェアや設備への投資 スペースとコストの両方が法外になる可能性がある インフラストラクチャは、要求があった場合、現在のビジネス負荷は最初のプロビジョニング以降に大幅に増加している可能性がある これに対応できる状態にあることを確認するため、通常手動で行われる定期的な検査とメンテナンスに関するオーバーヘッドも発生 テストが困難になり、コストも高い AWS Elastic Disaster Recovery (DRS) について AWS災害対策に基づく、物理的サーバー、仮想サーバー、およびクラウドサーバー向けの、完全にスケーラブルで費用対効果に優れたサービス 必要になるまでアイドル状態で、オンプレミスの DR インフラストラクチャに投資する必要がない AWS で弾力性のあるリカバリサイトとして使用 オペレーティングシステム、アプリケーション、データベースのレプリケーションを常時維持 企業は、災害発生後、数秒の目標復旧時点 (RPO)、数分の RTO を達成 例えば、ランサムウェア攻撃の場合、DRS は以前の時点へのリカバリも可能にします 現在のセットアップに合わせて必要に応じて拡張できるリカバリを提供 準備状態を維持するために時間のかかる手動プロセスがいらない 災害対策読み取り演習を実施する機能 サービス機能について 物理的サーバー、仮想サーバー、またはクラウドベースのサーバーからブロックストレージボリュームを継続的に複製 数秒で測定されるビジネス RPO をサポートできる リカバリには、物理的インフラストラクチャ、VMware vSphere、Microsoft Hyper-V、および AWS へのクラウドインフラストラクチャで実行されているアプリケーションが含まれる サポートされている Windows および Linux オペレーティングシステムで実行される、すべてのアプリケーションとデータベースをリカバリ AWS 上のサーバーのリカバリプロセスを調整し、数分で測定される RTO をサポートします 仕組みについて サーバーにインストールしたエージェントを使用 AWS アカウント内の選択したリージョンのステージングエリアサブネットに、データを安全にレプリケート ステージングエリアサブネットは、手頃な価格のストレージと最小限のコンピューティングリソースを使用、コストを削減 DRS コンソール内では、必要に応じて、別のAWS リージョンにある Amazon EC2 インスタンスをリカバリ DRS のレプリケーションとリカバリの手順を自動化してくれる 特別なスキルセットを必要とせずに、1 つのプロセスで災害対策機能をセットアップ、テスト、運用できます コストについて 長期契約や一定数のサーバーを契約する必要がない オンプレミスまたはデータセンターのリカバリソリューションよりもメリットがある 従量制料金制で時間単位で課金されます。 さいごに バックアップからの、データのリストアをテストすることが重要であるのと同様に、 継続的な複製やお客様のサービス利用に影響を与えることなく、コストパフォーマンスに優れた方法でリカバリ演習を実施できると リカバリを依頼する必要がある場合に、目標とお客様の期待に応えることができますので積極的に使うべきサービスだと思います。 次回は軽くチュートリアルを実践していきますので、合わせてお読みいただければ幸いです。

2021年11月23日にAWS Systems Manager (SSM)のFleet Managerで「コンソールベースのWindowsインスタンスへのアクセス」が発表されました。 ブラウザベースでRDP接続ができるようになっています。SSM経由なので、マネージドインスタンス（SSMに接続されたEC2インスタンス）であればインターネットからのRDP接続ができる必要もありません。実際に試してみました。 手順 ドキュメントはこちら。まだ日本語版はありません。 Systems Managerを開きます。 左のメニューペインから「フリートマネージャー」を開きます。 接続したいWindowsインスタンスを選択し、「Node actions」から「Connect with Remote Desktop」を開きます。 ユーザー名とパスワードを入力して「Connect」をクリックします。 リモートデスクトップ接続の確立が行われて… 接続されました！ 個別のセッションタブ（i-xxxxxというEC2インスタンスIDのタブ）ではブラウザウィンドウサイズに合わせて大きくデスクトップが表示されます。 セキュリティ周り セッションの記録 実体はSSM経由でのRDPの様子です。Systems Manager Session Managerを見ると、セッション履歴もちゃんと記録されています。ドキュメント名が「AWS-StartPortForwardingSession」となっているので、ポートフォワーディングでRDP接続していたことが読み取れます。 ネットワーク構成 このEC2インスタンスに適用しているセキュリティグループのインバウンドルール。外部からの接続は許可していません。 SSM経由での接続なので、必要なのは(a)EC2インスタンスから直接あるいはNAT経由でインターネット接続できるか、(b)EC2インスタンスの接続範囲内にSSMなどのエンドポイントが作成されていて、どちらかの方法でSSMに接続されていることです（参照：AWS Systems Manager経由でssh不使用のOSリモートアクセスを試す - Qiita）。 認証 認証は、まずAWSのマネジメントコンソールにサインインできること、次にWindowsにサインインできることの2段階のようです。今回はAWSマネジメントコンソールをIAMロールで使用していました（IAMユーザーでサインイン後、強い権限のあるロールへ切り替え）が、問題ありませんでした。WindowsへはAdministratorアクセスであれば、キーペアファイルないしその内容を指定することでもサインインができそうです。 しかし私が試した際には、管理者パスワードの復号に失敗しました。同じファイルでEC2の「接続 > RDP接続」画面からパスワードを復号・取得して、上のスクリーンショットのようにパスワード入力してサインインできましたし、RSAキーペアであることも確認しています。ファイルの問題ではなさそうな気がしますが、調べ切れていません。 クリップボード ローカルのファイルをコピーして、リモート（EC2上）のWindows環境にペーストできるか気になりましたが、これはできないようです。可能にする設定等があるものかはやはり調べ切れていませんが、とりあえず安全側なのでいいかなと。 おわりに これまではSSM経由でのRDP接続というと、(1)Administratorパスワードを取得し、(2)AWS CLIで aws ssm start-session してポートフォワーディングして、(3)RDPでローカルの転送ポートに接続、とわりと手間がかかる印象でした。今回のアップデートで、非常にSSM経由でのRDP接続が使いやすくなったと思います。 すべてマネジメントコンソール（Webブラウザ）上で完結する。 AWS CLIをインストールしていない環境からでも接続できる。 SSM経由でのRDP接続には、元々以下のような利点もあります。 インターネットからのRDP接続を許す必要がない。 プライベートサブネット内のEC2インスタンスにも接続できる（SSMエンドポイントなどを介してSSMに接続されていれば）。 OSの認証に加え、AWSの認証を必要とする（多段認証になる、AWSの認証に多要素認証やSSOを使うこともできる）。 いくつか調べ切れていないところなど残っていますが、まずはファーストインプレッション的に。活用していきたいと思います。 参考 AWS Systems Manager Fleet Manager now provides console based access to Windows instances with enhanced security protocols Connect using Remote Desktop - AWS Systems Manager AWS Systems Manager経由でssh不使用のOSリモートアクセスを試す - Qiita