2021-08-23

「AWSの基礎を学ぼう第五十五回 AWS Database Migration Service」 #awsbasics 受講メモ

AWS 勉強会

awsbasics.connpass.com

全く聞いたことの無いサービスの「CloudEndure と Application Migration Service」です。

セッション

CloudEndure と Application Migration Service のおさらい

講師：アマゾンウェブサービスジャパン、シニアエバンジェリスト亀田氏

昔

VM Import/Export
- EC2 AMI を作ってくれる
Server Migration Service(SMS)
- EC2 AMI を作ってくれる
- 差分コピー(90日間まで)に対応、ダウンタイムを極小化、エージェントレス
- エージェントインストール可能の場合は Application Migration Service 利用

Application Migration Service(MGN)

CloudEndure がベースのサービス
- MGN は CloudEndure と違い PrivateLink で閉域網利用可能
- 32bit OS 利用したい場合は CloudEndure
AWS サービスとして統合されている
オンプレミスにエージェントを入れて AWS へ移行させる
- IAM を事前に作って、アクセスキー/シークレットキーを設定する

移行パターン(7R)

リロケート: VMware Cloud on AWS
リホスト: Lift and Shift
リプラットフォーム: Lift & Reshape
リパーチェス: リプレース、買い替え
リアーキテクチャ: リライト、アプリケーションの疎結合化
リテイン: そのまま
リタイヤ: 廃止

リホストが、MGN のパターン

所感

200以上のサービスが AWS にあるから知らないサービスが次々出てきますね。
開発ではオンプレミス使ってないから、今のところはマイグレーションすることも無いかなーとは思ってます。
情シス部門とかみたいに、社内にレガシーなプロダクトや機器を抱えつつという状況だと使うことがありそうかな。

2021-08-16

「AWSの基礎を学ぼう第五十四回 AWS Database Migration Service」 #awsbasics 受講メモ

AWS 勉強会

awsbasics.connpass.com

「AWS 以外で DB 使ってないから、使うことないかなー」と聞き始めたのですが、それは勘違でした。

セッション

AWS Database Migration Service

講師：アマゾンウェブサービスジャパン、シニアエバンジェリスト亀田氏

商用 DB に比べて OSS の弱さはサポート
- AWS がサポートできる部分がある
- メリット：インフラ、拡張性、革新性、コスト最適化
AWS Database Migration Service(DMS)
- DB のデータ連携を支援するサービス
- 古い dump がそのまま入らないときなど利用すると楽になる
- Oracle 純正機能で移行できるときなどは利用しなくてもいい
Oracle -> AWS DMS からの移行先
- Amazon ES, Kinesis Data Streams, Aurora, S3, Redshift
DMS でサポートされている DB
- Relational, NoSQL, Analytics, Data warehouse
- Source: AWS のサービスもソースにできる
レプリケーション方式
- 物理レプリケーション：トランザクションログをターゲットに転送
  - DB エンジンやバージョンを揃える、DB 単位
- 論理レプリケーション：トランザクションログからDMLを作成
  - DB エンジンやバージョンに制限なし、テーブル単位
  - こちらのケースに該当する場合に DMS を利用する
文字コード問題
- DMS 内部で UTF-8 に必ずなる（SJIS なども一旦 UTF-8 になる）
- ReplaceChars 設定で補正

所感

最後の方ついていけなくなってしまった。
AWS にあるデータをソースとして、他の AWS サービスにマイグレーションもできるんですね。
それだけをとりあえず覚えておこうと思います。

2021-08-10

「ssmonline #14 真夏の夜の手順書トーク」 #ssmjp 受講メモ

勉強会 AWS

ssmjp.connpass.com

「アウトプットしないのは知的な便秘」でおなじみの ssmjp です。
「ヤマサキ春のサメまつり 2021」で、いろいろ間違って参加してから、ちょこちょこ聞いております。
ちょこっとだけメモ取ったので、アウトプットしないで捨てるよりかは備忘録に置いときます。

セッション

真夏の夜の手順書トーク

@tcshさん,@nlog2n2さん,@togakushiさん

自動化好きな人は手順書嫌い
- 手順書書けない人の自動化はひどい
- そして負債化する
CLIの手順書を出したらキャプチャーに置き換えられていった
- SIer とかだと辛いケース
手順書のコンテキストを意識
- ハイコンテキストだとやり直しが辛い
- 低コンテキストの手順にする
運用は事業継続のためのもの、そのための手順書
- 属人化をなくす
- 暗黙知を明示的な知識として知的財産化する
- 論理的な正しさを組み上げるプログラミング活動
非定常運用の手順書
- 実装できる部分は多いからすべき
- 緊急対応でも手順書は作れるはず
- 属人対応はOpen/Closeの基準とアウトライン程度でもすべき
手順書を放置して腐らせると、いざというときに使えない
体言止めはタイトルだけ
- タイトル以外は動詞をちゃんと使う
主語と目的語は省略しない
相対パスは使わない

所感

「自動化好きな人は手順書嫌い」と冒頭でありました。
仕様書がおいつかず、コードが仕様書になることはよくありますが、自動化されていればそこから読み取れるから「自動化できるているだけマシじゃないかな？」と思いましたが、そんなことはないでしょうか？
手順書を陳腐化させずにメンテする大変さと、仕様書をメンテしていくのは同じような辛さですね。
エンジニアはだいたいドキュメント嫌いだけど、マークダウンなどのテキストで作成 + Git で管理にすると、比較的ハードル低く続けれる気がします。

2021-08-09

「AWSの基礎を学ぼう第五十三回 Amazon CodeGuru」 #awsbasics 受講メモ

AWS 勉強会

awsbasics.connpass.com

CodeGuru 良さげですよね。
対応言語増えるといいのですが。

セッション

Amazon CodeGuru

講師：アマゾンウェブサービスジャパン、シニアエバンジェリスト亀田氏

Amazon CodeGuru

ソースコードの改善提案
- バグ修正ではない
- 無駄な部分の改善提案
- セキュリティな改善
  - 暗号ライブラリが弱いとか
  - SQL インジェクションの可能性とか

Amazon CodeGuru Reviewer / Profiler

Amazon CodeBuru Reviewer
- ソースコードのクリティカルな問題や発見が困難なバグを特定
  - AWS API のベストプラクティス
  - 並列処理、セキュリティ対応、リソースリーク防止
  - 機密データの漏洩、コーディングベストプラクティス、リファクタリング
  - インプットバリデーション、コードクオリティ
- Java, Python に対応
- 3種類のワークフロー
  - PR, リポジトリ解析、セキュリティ
Amazon CodeBuru Profiler
- パフォーマンス状況を可視化
  - 実行コストが高い行を特定
- Java, Python に対応
- エージェントを埋め込んで利用

セキュリティ

CodeGuru は一度ソースを AWS にコピーして解析する
- AWS の責任で漏洩などは守る
  - 規約は確認しておいてください
- PR のタイミングなどで解析
- Profiler をいれるとパフォーマンスとコストを計測できる
  - 本番環境で解析して提案

X-Ray or CodeGuru

X-Ray との違いは？
- X-Ray はログを元にパフォーマンスを可視化
- CodeGuru Profiler はアプリの中に入って実際の値をサンプリングして可視化

対応リポジトリ

CodeCommit
- GitLab 利用時は CodeCommit 経由にすることで利用可能
GitHub
- CodeStar が裏で連携
Bitbucket
- CodeStar が裏で連携

Amazon CodeGuru Security Detector

Java のみサポート
- AWS API セキュリティベストプラクティス
- Java 暗号化ライブラリベストプラクティス
- セキュアウェブアプリケーション
- AWS セキュリティベストプラクティス

Amazon CodeBuru Profiler

3種類のモード
- Overview
  - プロファイリングデータをボトムアップで表示
- Hotspots
  - プロファイリングデータをトップダウンで表示
  - CPU 使用時間が長いものから順に表示
- Inspect
  - 全体で複数箇所に存在するフレームを集約して表示
ビジュアライゼーションはスタックトレースのサンプリング
CPU ベース or レイテンシーベース
メモリプロファイリング
- どのオブジェクトがどれぐらい使っているか可視化
異常検知
- 過去のプロファイルと比べていつもと違うメモリの使い方をした場合
- SNS に通知可能

所感

Java と Python は、メインプロダクトのコアな処理では使ってないこともありすぐに活躍することはなさそうです。
いくつかのプロダクトでは利用している言語なので試してみたいですが、お値段がそこそこしそうなのがきになるところ。
Profiler 入れるのはすぐにはできなさそうなので、まずは Reviewer から試すのがお手軽ですかね。

2021-07-29

「JAWS-UG朝会 #23」 #jawsug_asa 受講メモ

AWS 勉強会

JAWS-UG朝会 #23

jawsug-asa.connpass.com

二度寝してて目覚ましに助けられました。

セッション

セッション① おひとりさまOrganizationsのススメ

講師：塚本牧生さん

おひとりさまAWS Organizationsのススメ from Makio Tsukamoto

www.slideshare.net

個人で Organizations で実現できること
- アカウント一覧が見れる
  - 管理アカウント+メンバーアカウント
- 支払いまとめれる
  - 管理アカウントにまとめられる
- 新規AWSアカウント作成が楽
ハンズオン向けに新規アカウント作成
- メリット
  - クオータ制限なし
  - AdministratorAccess でなんでもあり
    - PowerUserAccess だと IAM とかつくれない
  - 終わったらアカウント削除で消し忘れ請求なし
- デメリット
  - 無料枠は組織全体で1アカウント
- アカウント作成をルーチン化
  - アカウント名やルートメールアドレスの命名規則を決めておく
Organizations から AWS アカウントを作成する
- メンバーアカウントを作成
  - キャッシュカード登録不要
  - 電話番号の SMS 認証スキップ
  - 終わったらメンバーアカウント側で解約
    - 組織からのメンバーアカウントの削除はしなくていい

クレカなしで新アカウント作れるの知らなかった！

セッション② Amazon CloudWatchを勉強して水分補給アラームを作ってみた

講師：藤田直幸さん

speakerdeck.com

SOA は、監視ロギング解決の分野が一番大きい
- CloudWatch を学ぶ
CloudWatch
- メトリクス、名前空間、ディメンションで構成
- メトリクスは一定期間で自動削除
  - 1分なら15分保存、意図的に削除はできない
- ディメンション
  - メトリクスを一意に特定する名前
水分補給アラーム
- CloudWatch Events
  - Cron 式のスケジュールで2時間毎に SNS 実行指示ルール作成

資格も順調にとって、勉強のために自分用のソリューションを考えるのが面白かったです。

セッション③ AWS Well-Architected ドキュメントの歩き方

講師：平野文雄さん

AWS Well-Architected
- AWS 利用のベストプラクティスドキュメント集
- 読むのは辛い
Well-Architected 構成
- 一般的な設計の原則：カテゴリを超えた一般的な6つの設計原則
- 5本の柱：運用、セキュリティ、信頼性、パフォーマンス、コスト
  - 設計原則：柱ごとの設計原則
  - 定義
  - 質問
    - ベストプラクティス：質問に対してのベストプラクティス
      - 説明
      - 改善計画：ベストプラクティスの説明
ブログにまとめた
- https://dev.classmethod.jp/articles/aws-well-architected-guide/

ドキュメント読むの辛い...ググってヒットしたページをつまみ食いするのが主な利用方法になってます。
これ書いている人のほうがもっとつらそう。
AWS の中の人は、花形のイメージはありますが、ドキュメント整備している人は大変そうだ。

所感

Organizations は使ってますが、「Organizations から AWS アカウントを作成する」というのは知りませんでした。
新アカウントを作るために、いつもクレジットカードを準備して、作ってからすぐに組織に所属させていました。
すぐに組織に所属させるので、クレジットカードの引き落としは無いのですが、いちいち準備するのがめんどくさかった状況です。
会社で利用する場合は、クレカ準備のハードルが一番高かったのですが、この方式を使えばサクッと新アカウントを作っていくことができそうです。

2021-07-26

「AWSの基礎を学ぼう第五十一回 FSx for Windows / FSx for Lustre」 #awsbasics 受講メモ

AWS 勉強会

awsbasics.connpass.com

FSx 使うことあるかな。

セッション

FSx for Windows / FSx for Lustre

講師：アマゾンウェブサービスジャパン、シニアエバンジェリスト亀田氏

Amazon EFS

Linux 前提
NFS でアクセス
高可用性が考慮された分散ファイルシステム

FSx for Windows

SMB でアクセス
- SMB 2.0 - 3.1.1
Windows ネイティブなファイルサーバー
- NTFS
- Microsoft AD が必要
- DFS サポート
ENI 経由でアクセス
- SG 設定をしてアクセス制限
- ENI に DNS が払い出されて AD にて管理される
メンテナンスとバックアップ
- RDS と同様のバックアップウィンドウでの設定
  - S3 にバックアップ取得
  - 内部的には VSS 利用で I/O の中断は数秒
DFS 名前空間
- 複数のファイルサーバーが一つの名前空間として見える
  - 論理的に構造化されたファイルに見える

FSx for Lustre

HPC 向け
一時的なファイルサーバー
- 計算時だけ利用することが前提
セッション数が多い環境向け
3,600GB 単位で容量を設定
数百 GB/s のスループット

所感

Windows はワークフローで今のところ使う予定は少ないかな。
後学のために気になるところだけメモしました。

2021-07-19

「Tech Lead Night vol.0 - 各社のテックリードが、気になるテーマを徹底討論！ -」 #LF_techleadnight 受講メモ

勉強会

legalforce.connpass.com

セッション

スピーカー

加藤潤一氏 | Chatwork株式会社プロダクト本部コアテクノロジー開発部テックリード
道井俊介氏 | ピクシブ株式会社執行役員CTO
松木雅幸氏 | Nature株式会社 VPoE

テーマ① テックリードとエンジニアリングマネージャーの違い

Chatworkでは明確な定義はない
- 非機能要件が多いものを検証する
Pixivではテックリードという役職を明確においている
- CTOの一部を委譲
- 各事業部ごとや専門性が必要な技術にテックリードがいる
  - 部長やマネージャーはツリーにいるけどテックリードはツリー外
- テックリードがマネジメントを兼ねている場合もある
  - テックリードが必ずPMやスクラムマスターを兼ねるわけではない
Nature
- Web界隈ではCTOやVPoEを建てるのがトレンド
- 境界を作ることで隙間が出来る
- エンジニアが得意領域を補間し合うのが大事
- テックリードが徐々にエンジニアリングマネージャーに変わることもある
自己組織化は必要
- 一方、組織が凝り固まってサイロ化し過ぎても困る
- 組織に横串を通すのがテックリードの役目
  - ロールに役割を紐付けず越境させることも必要

テーマ② 『技術選定』はマネジメントの仕事？

基本的にはプロダクトを受け持つチーム
- アーキテクチャを自分ごととして捉える
- 個別最適になり過ぎてサイロ化してしまうのには注意
インフラやプラットフォームはある程度共通化
- 共通化と権限移譲のバランスが大事
- 横串でプラットフォームを見るチームと、プロダクトを見るチームで分ける
マネージャーは必ずしもエンジニアではない
- 技術選定を担うのがテックリード
  - マネージャーからは技術を剥がす
- 事業部ごとに技術選定する
  - テックリードとCTOが連携してリスクと情報を共有する
  - 各部署で責任が取れる範囲で自由に決める
会社をうまく利用して技術選定できるのがテックリードの醍醐味
- ある程度ポジションをもらってやるほうが楽しい
  - 言われたことをやるだけではつまらない
テックリードは目指してなるわけではない
- 日々技術でどうやって解決するかを考えてたらテックリードになる/なってた
- 自分でなりたかったり目指してたわけじゃない
  - 前のCTOが辞めるとき指名された
- いろんな依頼を断らないようにしていたらこうなってた
- 面白いことを勝手にやってれば、自然とテックリードになっていく

テーマ③ 早く採用しておけばよかった技術、早く採用しすぎた技術

パブリッククラウドを（世間より早くはしてたけどもっと）早くやればよかった
- 自分でやるのがかっこいい時代だった。
Kyoto Tycoonは良いものだったけど廃れていった
- トレンドには早すぎるのもよくない
オンプレ前提をクラウドに設計し直すのはかなり難しい
- もっと早期にしておけばよかった
権限管理、シングルサインオン周り
- 社員が増える前にやるべき

テーマ④ エンジニアの組織文化をどのように作っていくのか？

エンジニアはエモさを大事にする
エンジニア組織でもエンジニアだけに閉じない
- エンジニアを特別扱いしているように見えるとよくない
- エンジニアしか尊敬しないみたいな傾向を持ちがち
  - エンジニアじゃない人を尊敬していることも発信して理解してもらう
Pixivは事業部が別れているのでエンジニアもビジネス職も同じ組織
- エンジニアギルドという仕組みがある
  - エンジニア同士で1on1したり技術評価しあう
  - 互助会
社内コミュニティで勉強会などを行いコミュニケーションを取る
チームを大事にする
- チームを解散するくらいなら仕事を変える

テーマ⑤ 開発チームのスキル構成の理想

シニアとジュニアの構成、フルスタック or スペシャリスト
事業中心に人を組み込む
- リソースの管理は事業部長
- CTOはアドバイス
失敗の経験も大事
チームでスキルマップの偏り発生
- テックリードが全てを補うのは難しい
- チームで補間し合う
- 機能ごとの知見をメンテナンスするのが大事
  - アサインや採用の相談が可能になる
CTO/テックリードが把握できないケース
- 適切な人に権限移譲
- 1on1 で若い人から教わる
  - 偉くなると失敗を恐れる
  - 他者から学んだり教わったりする姿勢が大事
- 全知全能ではない
スキルマップは全社でやらない、チーム単位で行う
- 全社は収拾がつかなくなり、運用されなくなる
- ビジネスの人も入れる
  - ドメインによってはセールスのほうが詳しい
- 一人に依存したスキルがあると積む
  - 最低二人にすべきスキルを見て考える

所感

テックリードを拝命してますが
「テックリードってなにすればええねん？」
と言う感じで、迷うことしか無いので藁にもすがる思いで聞いてました。

各社のテックリードの方々は、やっぱりとてもしっかりしてますね。色々ヒントをもらえた気がします。