RecoChoku Tech Night #09 4社合同 AWS re:Invent参加レポートに参加した。その際のメモ。

re:Inventについて

登壇者の意見まとめ
・徐々に参加者は増え、5万人に
・セッションだけでなく、ワークショップやハンズオンなど手を動かすイベントが多い
・EBCという、サービス開発者と直接会話できる機会がある(CloudFrontとS3の開発者と有意義なやり取りができたらしい)
・日本では味わえない熱量を感じられる
・サーバレスの時代に(コンテナよりもLamda的な観点を受けた)
・AWSが何を大事に思っているかを肌で感じられる

気になったサービス – 株式会社レコチョク 権藤 洋一郎氏

・Quantum Ledger Database (QLDB)
　フルマネージドの台帳管理サービス
・DeepRacer
　強化学習型のラジコン
　いかに自動運転をさせるかがポイント
・Visual Studio CodeでもLambdaを扱えるように
・オンプレミスのレガシーなサービスをAWSに持っていくためのサービスも増えていた

Amazon S3 Intelligent Tiering について – 株式会社ミクシィ 清水勲氏

・380万人が使うNo.1家族アルバムアプリ「みてね」のSRE
・Intelligent TieringはS3の新しいストレージクラス
・データを最もコスト効率の高いストレージクラスに移動してくれる
　・128KB未満のオブジェクトは自動階層化に適していないため、常に高頻度アクセス層に格納される
　・通常はコストが下がるはずだが、モニタリング・オートメーション費用のため容量が小さいファイルが多いと割高になる可能性あり
　・事前に分析することができる

AWS LambdaにサポートされたALBで開発してみた – 小林 真弓氏

・ALBのバックエンドにLambdaを置くことができるようになった
　・リクエストとレスポンスはテキストかバイナリしかNGのため注意が必要

API Gatewayとの違い

・ALB配下にEC2などと共存することで、認証だけはLambdaに、という処理が可能になる
　・Lambda自体の知見は多いが、まだALB配下の知見はほぼない状態なので、現状は管理が複雑になる可能性大
・RestAPIを利用するための複雑な機能や、WEB SOCKETといった別のインターフェイスが必要な場合はAPI Gatewayが優勢

Amazon Personalizeの紹介 – 福治 菜摘美氏

・機械学習できない人でも利用しやすいサービス
・HRNN Recipe(2017.7 映画のレコメンドで一番良い結果を出したレシピ)など多くのレシピを利用できる

Amazon Forecast の紹介 – 岡崎 拓哉氏

・予測データを簡単に作成できる
・売上予測などが作成できるかも

AWS Transfer for SFTP で◯◯してみた – 株式会社フォトクリエイト 野口 孝昭氏

・カメラマンの納品手段が5台のFTPサーバーと共有ストレージ
・積もり積もって画像容量は3ペタバイト。10億枚の写真
・API Gateway経由のLambdaを叩くことで認証は自由にできることがわかった
　・IP制限がかけられず様々な国から攻撃されることが辛い

SageMakerアップデートの紹介とデモ 株式会社フォトクリエイト 林 裕一郎氏

・SageMaker Ground Truth
　・教師あり学習の正解データ作成をサポートするサービス
　　・今までこれ　というものはなかったため、それになれるか
　　・あいまいなデータは人間にラベルを作成させる

Custom AWS Lambda Runtimesの紹介とデモ – アマゾンウェブサービスジャパン株式会社 畑 史彦氏

・言語ランタイムを持ち込むことで好みの言語を利用するCustom Runtimesをサポート
　(ランタイムを持ち込む時点でLambdaのメリットはだいぶ減っている)
・パートナーからPHPやCOBOLが提供される予定
・例えばまだサポートされていない最新の言語や、サポートがきれた言語を利用することが可能
　・ただし管理対象が増えるため、デフォルトのLambdaを利用することがベスト

働き方改革とセキュリティ対策を両立させる方法に参加した。
齊藤愼仁氏と河野省二(クラウドセキュリティのガイドラインやISO27002を策定した人)氏の発表込みの対話だったため、自分なりに理解したことを記載する。

・ITが企業のコアになっている。ITを抜いたら会社がなくなるような時代になっており、インターネットを有効に使えない企業は衰退していく

・セキュリティの目的は(何かあったときの)説明責任、事業継続であり、手段として情報保護を実施している
　・セキュリティはコスト
　　・ルールで縛るはシュークリームを毎週買ったほうがセキュリティは向上する
　・事業継続の観点として、例えばM銀行など週末メンテナンスするのであれば、クレジットカードを女子高生にも持たせるべき(じゃないとお金を下ろせない女子高生は機会損失する)

・ファイヤーウォールや出口対策で守るといった中央集約型のセキュリティは限界が来ている
　・社外でインターネット越しに作業することが多くなっているため
　・セキュリティで一番守らなくてはならないものはデータであり、中央制約型では漏洩したときなどの対応が難しい
　　今よく聞くCASBやSIEMについても今後なくなっていく
　・Splunkでデータを集めてゴールではなく、解析と対応が重要だがそこまで運用できている企業は少ない
　　またログを自分たちで持ちたいということが傲慢。第三者に預けることがとても大切(何かあったときのログとして改ざんされている可能性が低い)
　・VDIベンダーの売上の8割が日本。またVDIベンダーの株価は下がり続けている
　　・Desktop as ServiceについてMicrosoftも本当はやりたくない
　・管理の粒度を小さくすることが問題発生時のビジネスへの影響を小さくする。中央集約型では大きすぎる
　　・例えばモバイル端末管理はMDMではなくMAMに移っていくべき

・分散管理型としてVPNを使うことがある
　・ユーザにとって使いにくく、その結果シャドーITが生まれやすくなる
　・MACアドレスやIPアドレスは偽装しやすく、結果的にVPN接続元が正しい端末か(ゼロトラストネットワークの考え方)を判断することは難しい
　　・最近ではサービスを提供にあたって、IPスプーフィング対策ができていますか？という質問がある
　・端末を信じるためにはTPMを利用するべし
　　・例えば中国だとお札が本物か信じられないから電子決済が普及している。毎回オーソリしたいらしい

・それは本当に会社のPCか？本人か？を証明するためには
　・IDaaSを利用した匿名インターネットの終焉がくるかもしれない(誰がいるかわからないのであれば名乗れば良いの精神)
　　・AzureADやGoogleIDなどはIDだけでなく端末なども登録できる
　　　・ただしGoogleの戦略はブラウザでとどまっている
　　　・AWSはリソース屋のため今後なくなっていく可能性がある
　・WEBはなりすましを防ぎにくい機構のため、匿名インターネットがなくなっていく場合は、今後なくなっていく。より専用アプリ化が進む
　・すべてのデータに証明書をつける必要がある
　　・例えば回線金額未払いだとスマホにある証明書を外部で削除している
　・オススメの書籍
　　https://www.amazon.com/Zero-Trust-Networks-Building-Untrusted/dp/1491962194/

・分散管理型のポイントとして権限を現場へ移譲しつつも、利用状況を把握する仕組みを用意すること、つまりエンドポイントセキュリティ必須
　・SOCをエンドポイントで稼働させる
　・Microsoft 365がオススメらしい(DLPなども含まれている)
　https://www.microsoft.com/ja-JP/microsoft-365/business

・バッドノウハウとして、構成検討の際に既存の仕組みを流用しようとすると、すべて失敗する

クラウドネイティブの職場環境

・ゼロトラストネットワークの考え方が以下を支えている、らしい
　・出社時間自由。オフィスはあるが出社は推奨しない
　・給料は自己申告制。議論や意見無しで書いた金額がそのまま支払われる
　・必要な物品を法人クレカで購入可能

・オンプレADを意識して作成しているSaaSがあるため、オンプレADはある。ただし危険であるため使いたくない
　スキーマ拡張すればAzureADと接続できないらしい

・AzureADにログインする際に、本当に本人か？もし危険なネットワークである場合は安全な環境を作ってから接続するような仕組みが用意されている
　・ゼロタッチデプロイメントなど、起動したら自分の名前で作業するような仕組みもある
　・暗号化されていない通信などを検知したときに自動的にVPN通信になる
　　つまり相手先が信頼できない場合のみVPN通信させる

・MACはziftenを利用している(Microsoft 365と連携可能、統合管理できる)
　・ネットワーク機器など既存のコストがなくなる。Microsoft 365も含めると高額にみえるが、いつか逆転する

・アンチウイルスではなく、EDRがオススメ
　・Windows10のEDRはエージェントレス
　　・Windows10のメジャーアップデート時のメーカーへの確認などが不要

Developers.IO 2018に参加した。その際のメモ。

「コンテナジャーニー」〜明日から速攻始めるAWSでのコンテナ導入運用〜 濱田孝治氏

「コンテナジャーニー」〜明日から速攻始めるAWSでのコンテナ導入運用〜 #cmdevio2018

すべて記事にわかりやすく記載されているが、せっかく書いたので、、メモを残しておく。

コンテナジャーニーのススメ

・コンテナ = dockerという前提での発表
・導入にあたり様々な障壁がある
　導入時に考えるべきは、アプリケーション開発と運用すべて
・スムーズな導入のためにもコンテナジャーニーを提案する
・最初に一人で利用してみる。手始めにPandocの利用(document変換ができる)がオススメ
・テストツールのイメージ化から進めるとよいかも

どこにイメージをおくか

・Docker Hub：無料で1つプライベートイメージを保持可能
・Docker Hub はパブリックだから使えない場合は、ECRを使おう！(逆にパブリック公開はできない)
・IAM制御するため、特定のユーザだけはアップロード可能、その他はダウンロードのみなど運用がよさそう

どこで実行するか

・Fargateを利用すると、コンソールからEC2が全く見えなくなる。EKSとはまだ連携できない

Fargate 注意点

・設定は環境変数に。DB接続先などは外から与えないといけない
・ログはバッファリングしない。標準出力するようにする
・ログドライバはawslogsしかない(標準ではCloud Watch Logsのみ)

その他

・Subversionだとしてもフック機能を利用して、Gitにコミットするようにすればうまくいくかも
・コンテナのセキュリティを検査するツールが多々ある

基礎から応用までじっくり学ぶ「AWSでのネットワークの作り方」 梶浩幸氏

#cmdevio2018 基礎から応用までじっくり学ぶ「AWSでのネットワークの作り方」で登壇しました。

・EC2へ固定IPアドレスを利用すると、CloudFormationで問題が発生することがある
・VPC作成時に暗黙的にルーターが1つ作成される
　・subnetから別subnetにアクセスする際にこのルーターを経由する
・経路はルートテーブルで設定する
　・ネットワークACLはこのルーターとsubnetの間のFirewallのイメージ
・VPC PeeringのMTUサイズは1500byteのみ
・NLBは1アーム構成(戻りバケットはNLBを経由せず、EC2が直接クライアントと通信する)
・NLBを利用したPrivateLinkは他社と連携しやすお(IPアドレス形態が重複しても良い)

いつでもどこでもオフィスになる魔法の仕組みWorkSpaces 豊崎隆氏

Developers.IO 2018 で「いつでもどこでもオフィスになる魔法の仕組みWorkSpaces」を話しました #cmdevio2018

・WorkSpacesはAWSのVDI(サーバ上のデスクトップ環境を提供する基盤のこと)
・ChromeBookから利用すると、キーマッピングがうまくいかないらしい(半角・全角が機能しない？)
・4172ポートで通信する
・満員電車から解放される！
・リモートワークするときは、BYODや働き手のパフォーマンスが向上するルールを検討しなければならない

WorkSpacesの利用を制限することができる

・MFA
・送信元IPアドレス
・デバイス認証(クライアントへ証明書をインストール)
・グループポリシーでの制御

費用

・Windows10で1台月額43ドル
・Office+セキュリティソフトで月額15ドル

ライセンス持ち込み

・OSのライセンスを持ち込む場合、4ドル値引きされるが、制約が多々ある
　・Didicated Instance利用必須
　・最低200WorkSpacesなど

運用について

・AZ障害が発生したときに、余計にIPを消費するため、ネットワークのIP数は余裕を持って設計したほうがよい
・WorkSpaces Application Manager(東京リージョン利用不可)に期待
　アプリケーションを配布することが可能

知って備えれば怖くない！ AWS移行ガイド 加藤諒

Developers.IO 2018 で「知って備えれば怖くない!AWS移行ガイド」を話しました #cmdevio2018

・移行チームを作る際に、ベンダーで悩むことがあるかもしれない
　その場合は1社であることにこだわらず、適切な箇所に適切なベンダを利用したほうが良い

DevOps:変化の激しい環境でビジネス競争力を向上させる具体的な方法 藤村新氏

Developers.IO 2018 で「DevOps:変化の激しい環境でビジネス競争力を向上させる具体的な方法」を話しました #cmdevio2018

・DevOpsという言葉がずるいと感じている
・最初は「Dev vs Ops ではなく仲良くしましょう」であったが、その後さまざまな解釈がある(明確な定義がない)
・アジャイルやツールなどさまざまなものでDevOpsが成り立っており、すべての成功はDevOpsが理由とされているためずるいと感じる
・クラスメソッドのDevOpsサービスの目的はビジネス競争力の向上
・ビジネス競争力を向上させる具体的な方法(リードタイムを短くする)
　→VSMを実行して、ボトルネックを排除していく

MANABIYA #2 – teratail developer days –を閲覧した。
YouTubeで配信されていたため、閲覧した。その際のメモ。

3限目 (13:30 – 14:10)：【2-3】Web × AI

・カーソルやタップの動きやスマホの傾きをよみ、特定コンテンツを先読みすることは実装されている。
　例えばGoogleマップは下に動かすとその先を読み込む。

・ブラウザに実装されると嬉しい。
　2012年にはXboxでユーザの動きを予想して、パケットを先送りをしていた。
　ゲームや動画配信のほうが先送り技術が多い。

・学習モデルを作成することはWEBでは費用対効果でのメリットが少ないため
　マイクロソフトが学習モデルを用意するサービスも用意している。

・Sketch2Codeを利用するとワイヤーフレームからHTMLページを作成できる。
　マイクロソフトの方針として、AIで人を置き換えるではなく、AIで人のめんどくさをなくすアプローチをしている。

・Adobe Senseiは被写体をくり抜くなどを実施でき、裏ではマイクロソフトのAIが動作している。

・マイクロソフトはGitHubを買収したため、そのコードを解析している。
　IntelliCodeというプラグインは解析結果をもとによいコードがかけるよう支援する。

・アミューズメントパークでは笑顔かどうか判定して、満足度を測るなども可能に。

無線LANことはじめを聞いた。その際のメモ。

Wi-Fiについて

・Wi-Fi：親しみやすくするため認知度をあげるための名称。登録商標
・今後は専用ロゴを使って、どのWi-Fi規格で通信するかを視覚化していく流れ
https://www.wi-fi.org/news-events/newsroom/wi-fi-alliance-introduces-wi-fi-6
・CSMA/CD：昔は1つの同軸ケーブルでホストがつながっており、その際のコリジョンを防ぐための技術
　(コリジョンは電圧が重なり、範囲外になることで検知する)
・無線はCSMA/CAを利用しており、有線と無線の大きな違い

W52,53,56

・W52/W53は屋外では利用できない
・W53/W56の場合レーダー波を検知すると強制的にチャネルが変更される
　・電波送出時に1分間はレーダ受信有無を確認するため使用ができない(救急車が車道優先されるイメージ)
　・気象レーダーや空港の近くや海沿いで発生しやすい

事前サーベイ

・ネットワークを事前に調査してヒートマップを作る
http://www.ikeriri.ne.jp/develop/sitesurvey/index.html
・サーベイの際の閾値について、一般的な無線LANは60-75dbあればいいらしい

PoEがLANケーブルのどこ芯を利用しているか

・1000BASE-Tでは8芯すべてを信号線として用いている。
　このため、ギガビットハブにPoE対応機器をつなぐとリンクアップしなかったり速度が遅くなってしまう場合がある。
　そのような場合は100BASE-TXのハブにつなぎかえるか、1,2,3,6ピンのみ結線されている4芯のみのケーブルを用いるとよい。

AWS Systems Managerのススメを聞いたので、メモする。

前準備

・EC2インスタンスへのIAMロール(AmazonEC2RoleforSSM)が必要
・SSM Agentが必要
　・最新のAMIにはインストール済、なければ手動で
　・サポート対象：Ubuntuは12.04LTSから
・インターネットのアウトバウンド通信
　・もしくはSSM・EC2・EC2Message・S3へのエンドポイント通信が可能なこと
・SSM自体の金額は無料

できること

・パラメーターを保存する
　・環境ごとに異なるデータを保存可能
・RunCommand
　・コマンドを実行する
・Autometion
　・起動→パッチ適用→AMI作成→停止などが可能
・ステートマネージャー
　・スケジュールでRunCommandを実行する
・Maintenance Windows
　・Lambdaなどを実行することができる(理解しきれなかった)
・セッションマネージャー
　・ブラウザでシェルを実行することが可能
・インベントリ
　・定期的にサーバの情報を取得する

ベストプラクティスなど

・踏み台が必要だったサーバに直接対応できる
・スクリプト実行はSSMを利用したほうが、スクリプトの管理が容易になる
・IAMを利用して利用可能な時間に制限を設けることができる
・コマンド実行結果(lsなど)が遅かったりすることがあるらしい

クラウドは次の時代へ。これからのマルチクラウドを４人のスピーカーが語り尽くすへ参加した。その際のメモ。

ビックデータ分析基盤の成長の軌跡 – 白子 佳孝氏

・クライアント(リクルートと契約した企業)とユーザを結びつけるマッチングプラットフォームを開発している

・Mirror-Redshift
　・金曜日の夜にスナップショットをとり、そこからクラスターを作りデータ鮮度を求めない分析をするようにしていた
・2017年にBigQueryの導入によって、大規模に環境が変わった
　・データやユーザが増えても性能劣化が起きない、キャパブラ不要なDWHに乗り換える流れに

・今後やりたいこと

クラウドに関わる営業の本音、クラウドサービスの使い分け – 蔦野 岳人氏

オラクルとOracle Cloudについて

・オラクルは今大きな変革の中にある
　売り物がON-PREMISEからCLOUDへ
・Oracle Cloudはオンプレミスからクラウドへの完全互換性を謳っている
・ボトルネックを排除したアーキテクチャが売り
　元Amazonの人間とGoogleの人間が作っている
・IaaSでは低コストに力を入れている

今後営業に必要なマインドセット

・薄利多売のビジネスであることを理解すること
・クラウドは小さく入り込んで、大きく育てる
・営業先は情シスだけでなく、他部署へのアプローチも可能

マルチクラウドについて

・メリットはテクノロジーのいいとこどり、デメリットは運用の複雑化

シャドーITへの対策として -CASB-

・防いだ事例
　・Dropboxの私物利用
　・転職にあたり顧客データの持ち出し
　・インスタンスを起動して、コインマイニング

少し違った目線で考える、マルチクラウドのメリット、デメリット – 山田 雄氏

・ビールを奢れば、データ基盤の相談に乗ってくれるらしい

81

・81％ – クラウドを使っている企業がマルチクラウドである割合
・ActiveDirectoryやG Suiteなどを利用しているとマルチクラウドとしており
　なぜかマルチプライベートも入っているため割合が高め

各クラウドベンダーの姿勢

・AWSは否定派かも。CEOのインタビューから、複数のシステムの学習コストがかかる
　ボリュームディスカウントを考えると1つのほうがよい
・GCPはマルチクラウド、ハイブリッドクラウドを推奨している
　GCNextの3大メッセージに、ハイブリッド・マルチクラウド・オープン戦略がでていた

境界での問題にマルチクラウドは弱い

・S3からGoogleへデータを送信したときに、gsutilを使っていると中間ファイルが残るなど、スムーズに動作しない部分があった
　AWSへ問い合わせたところGoogleのツールなので、、Googleに問い合わせたところS3のため、、結局コードを追うことに

技術以外のメリットと、ちょっとしたデメリット

・AWSやGCPなど、人脈が広がり、横連携が強くなる
・サンフランシスコ(Google Cloud Next)、ラスベガス(re:Invent)にいける！
・技術的戦略がなく楽しい！BigQueryもRedshiftも利用できる
・両方の新サービスを追えない(勉強コストの増大)
⇒絞って学習している。現状GCPのビックデータ周りは把握しているが、AWSは理解できていない部分がある
・マルチクラウドという観点でのメンバ採用が難しい

マルチ クラウドだけでいいのか？ AI/IoT時代のクラウドのあり方 – 山﨑 亘氏

・ウフル：スワヒリ語で自由を表す

IoTのキーワード – 分散と更新

・例えば来場者の画像を取って、クラウドに送るような場合、次のようなデメリットが発生する
　・レスポンスが悪い
　・通信コストがかかる
　・セキュリティが心配
・上記場合は、データをエッジ側で処理すれば問題は解決する
・しかし運用していくと、次のような要望も出てくる
　・AIモデルの更新が必要
　・センサーデータ取得の間隔や位置も更新が必要
・これらの解決策として、enebularを開発している

ssmjp 2018/08 本当にあった怖い話に参加した。その時のメモ。

ssmjp:インフラ、運用がメインの何でもありの勉強会

Naomiさん

・ユーザ企業にて情シスをしており、以前の会社の話
・ファイルサーバやADなど、「Environment 45℃」で全サーバが停止
・推奨される最高周囲温度35℃
・サーバ増設による冷却装置付きのサーバラックのキャパオーバーが原因かも？
　2011年は輪番停電で扇風機がなかったが、ダイソンだけが在庫があった
・エアコンを数百万かけて設置することにした
　欄間を閉じると消防法のためスプリンクラーと警報機が必要になり高額となった
・しかしエアコンの納期は10月と夏を過ぎていたため、以下対策で乗り越えた　
　・ビル管へ空調24時間稼働依頼
　・空調温度をさげる
　・温度状況を計測して、サーキュレーターで対策
・外部監査はサーバラックに鍵をかけるという決まりがあったが、セキュリティリスクを許容して、事業継続リスクを優先で乗り切った

データセンタ運用であった本当に怖い話 @tcshさん

・予算のない部署のサーバラック
　・42Uフルで抜けない、差せない
　・ただし背面は寝るには最高の気温
　・熟睡していたら、あのラックの背面から足でているけど起こさないでね
　　・知らないうちに自分が設備扱い
・データセンターの電源容量枯渇
　・配電盤が溶融し、5秒後か5時間後にショートする状態に
　・シャットダウン大会
・電話局がリアルダンジョンで死ぬかと思った

皆一度は経験する、あり得ない話 流しのSEさん

・独立した上司に遊びにこないかと誘われ、客先に連れて行かれ、メイン担当者として紹介されたお話

今年最凶の怖いはなし 片山昌樹氏

・ナビプラスはセキュリティ全般をサービスにしている(インシデントレスポンス、フォレンジック、脆弱性対応)
・Huawai怖い
　・利用規約に口座番号や友人情報、リアルタイム位置情報やFacebookアカウントやTwitterアカウント情報などを取得を示唆する文章がある
　・米国政府から名指しで、個人情報を抜くメーカーと言われ、流通禁止の法律が施行されている
　　しかし、日本では大々的に販売されており、モバイルWi-Fiの90%はHuawai(わからないようにしている)
・試しにMateBook Eシリーズを調べてみたところ
　・Webカメラが写真を撮ろうとしている
　・マイクはミュートでも音を拾う
　・query.hicloud.comというHuawaiデータ取得用サイトなどに接続している
・Xiaomiを現在調査中
　・データのPOSTが多い
　・MDMサーバに定期的に通信している

　

運用におけるシェルの役割とそのあり方を考える – 山下和彦 氏

資料：運用におけるシェルの役割とそのあり方を考える

GMOペポバのサービス – ロリポップレンタルサーバ

・秒間2万8千アクセス/秒(DoSを受けた際はこれ以上)
・ビーク8Gbps

Shellに対するいくつかの考察

・Shell = Shell Script (bashで記載されたものを表す)
・RedMonk社(StackOverflow・GitHubでの人気度)によると、言語としては12位くらい

Shellの特徴

・メリット
　・パイプ、オプションを利用した強力な組み合わせ
　・ほとんどの場合は導入コストが低い(インストールの手間なし、依存性なし)
・デメリット
　・テスト実装、変化に強い実装、再利用性の高い実装は苦手

ライフサイクル観点からの考察

・パイプ、オプションが強力すぎて、熟練者でないと見にくいことがある
⇒開発効率化には最適であるが、複数人での運用保守には向いていない(運用の際に負債として残る可能性あり)
・携わるメンバがShellに詳しければ問題ないが、Shellに学習コストをかけるかというと、
　WEBエンジニアは覚えることが多くベターとは言えない

・例外として、USP研究所のようにShellに特化したユニケージ開発手法などが定着している場合もある
　・RDBを利用せず、テキストファイルによってデータを管理

言語特性観点からの考察

・長期的な運用には不向き
・変化が少ない局面については有効
　・バックアップスクリプト
　・監視系スクリプト

なぜ人類はShellをかかなくなったのか？

・Infrastructure as CodeによってLLやGoを書き始めた
・自動化の高度化
　LLやGolangで簡単にプロセスができ、人が介在せずとも処理ができるようになったため
　処理を集めてjob.shとして実行することなどを、自動化と呼ぶ時代ではなくなった

それでもShellが好きな人も

・人は得意な言語で書くため、評価にも反映させる

なぜGolang？

・システムプログラミングに必要なAPIが一通りそろっている
・可搬性が高く、サーバに配置しやすい

まとめ

・長期運用するなら、Shellを頑張るよりも、他の言語で対応したほうが幸せになる

知らなかったこと

・shellcheckというshellの記法をチェックするようなツールもある

サーバーやNW機器の構成・設定管理に困ってませんか？簡単に最新状況が把握できるインベントリ収集ツールの紹介 – 船井 覚 氏

資料：サーバーやNW機器の構成・設定管理に困ってませんか？簡単に最新状況が把握できるインベントリ収集ツールの紹介

Open-Audit

・コミュニティ版と商用版がある
・20ノードまでは管理可能
・エージェントレス型
・SNMP,WMI,SSHでアクセスして、情報を取得する

できないこと

・収集のみ、設定変更はできない
・時系列での履歴管理
・インデント管理、資産管理
⇒OpenPIEを利用すればできるように

OCS Inventory NG

・エージェント型
・コミュニティ版のみ

ノウハウ丸ごと共有します！ハートビーツの24/365体制を支える人材育成 – 倉持亘 氏

感想

・主体性(自分で考える)を大切にしている
・手を動かさないと身につかない
・障害時に大外ししないことを意識する
に共感した。

24/365を支える体制

・3交代制であり、3チームでローテーションしている
・1チーム5-6人で、役割がある(主担当と副担当、研修生)

目指す人物像

・なぜそうなるかを理解できる。自分で理解して、答えにたどり着ける人材(原則原理)
・技術はツールであり、このツールを利用して顧客へ価値を与えられる
・迅速に復旧までたどり着ける

人材育成におけるテーマ

・主体性
　自分で考えさせる。座学よりも、手を動かして理解してもらう(でなければ身につかない)

研修内容

研修生

・未経験者も雇うため、サーバ構築から障害対応までの基礎を教育する

サーバ構築研修

・目的：LAMP環境の仕組みを理解する
・タワーPCを渡して、あとはよろしく！チェックポイントは提示するが、構築の手順は提示しない
・やっていいこと、悪いことを学ぶ
・たくさん失敗させて、たくさん学んでもらう
・質問に対して、答えを伝えるのではなく、なるべく本人が答えにたどり着くように誘導する
・やったことはBacklogにエビデンスとして残してもらう
　・後で担当者が方向性があっているか確認する
　・ググってコピペしたものではないか確認するようにしている(自分の言葉でかけているか)

ロールプレイング研修

・目的：以下を身につけてもらう
　・技術だけでは顧客に価値を提供できない
　・技術がないと仕事はできない、
・顧客とHBのエンジニアという設定でロールプレイング
　顧客からアバウトな相談事を受けて、必要な情報を聞き取り、顧客の解決策を検討し、プレゼンしてもらう
・チェックポイント
　・Quick & Dirty (完ぺきではないが素早く)を実践できているか
　・顧客を理解できているか(サービスの理解、ビジネスの理解)
　・技術的に正しいことを言っており、もし不明瞭なことがあった場合に持ち帰っているか

障害対応研修＆実践

・障害対応フローを覚える
・調査コマンドを課題ベースで覚えてもらう
　使い方の詳細は説明しない。後ほど理解できているか確認する
・座学で学んだことを実際の障害で対応してもらう

フィードバック

・現場ではうまくいかないことも多いため、フィードバックを実施している
　・その場でのフィードバック
　・Backlogを利用したフィードバック
　　目的：振り返る機会を作る、指導者と研修生の認識をなくす
　　日報のようなものに、わからないことなどを記載してもらい、後日認識合わせをする
　・KPTを使った振り返り
　　・P(自分に足りないところ)：指導者の考えるPと研修生の考えるPのギャップを埋める
　　・T(Pをどうやって身につけるか):なるべく自分で考えさせる
　　・隔週実施

副担当

主担当面談

・主担当とは：シフト内の障害対応の責任者、すべての障害に目を通し、副担当に仕事を割り振る役割
・目的：主担当に必要なスキルを身につける
　・主担当のロールプレイング
　　・災害時のロールプレイング
　　・複数障害が発生した場合のロールプレイング
　　　・面談してフローを作成していくイメージ
　　　・チェックポイントとしては、優先順位をつけて、正しく仕事を割り振れるか、
　　　・論理的に切り分けて大外しせずに復旧までたどり着けるか

育成の課題

・指導者への指導
　人によって教え方が上手、下手がある
・フィードバックする時間の確保
　日頃の業務の中でフィードバックする時間がないときがある

質疑応答

・障害でパニックになる人に対してどうしているか？
⇒自分に自信がないことが原因だと思うため、小さい成功体験を積み重ねるよう教育している

・自分はできている思っている主担当に対してどのようにアプローチしているか？
⇒IT業界は流れが早いため、別途研修を設けている

「使ってみた」では終わらせない！ AWS GuardDutyを使ったサイバー攻撃の検出・分析45分スタートアップ講座 – 鈴木研吾 氏

資料：GuardDutyを使ったサイバー攻撃の検出と分析.pdf

感想 – というよりも知らなかったこと

・ArcSight、SplunkといったSIEMツールがある
・サイバーキルチェーンという標的型攻撃における攻撃手順を標準化したものがある
　これをもとに多段防御を検討することができる

GuardDuty 素晴らしいところ

・GuardDutyは検知だけのため、システム的な影響なし
　内部ではログをコピーして分析するため、遅延が発生することはない
　中の人に聞いた時も、ただただONにするだけでよいとのこと
・金銭面への影響についても、1ヵ月でどれくらいかかるかチェック可能

なぜGuardDuty

・AWSでは想定すべき脅威の種類が増えて、今までの検知ロジックだけでは不足している
　今までの検知が古いというわけではない

オンプレミス時代にはなかった想定すべき脅威の種類

・クラウドサービスとしてのアカウント
・リソースと権限
・動的にスケールするリソース
・Pay as you Goなリソース

GuardDuty in Folio

いくらかかっている？

・11アカウント全てON、$6.38/day
・SOCサービスは月間20万円ほど

誤検知ある？

・とても少ない
・もし誤検知があれば、その条件のアラートを無効にする機能が最近リリースされた

ユースケース？

・GuardDutyは集約する機能しかもたないため、CloudwatchからLambdaに流している
・検知したら、自動的にスナップショットを取得し、別VPCに展開し、フォレンジックするような仕組みを用意することも可能