おふとんの中から

その辺に転がってるエンジニアの備忘録

トップ > Tech > JAWS DAYS 2019に行ってきた #jawsug #jawsdays

JAWS DAYS 2019に行ってきた #jawsug #jawsdays

Tech 勉強会 AWS

ゆいなです。

なかなかブログに手が出ず、前回のlambdaの話ももうちょい続きがあるのですが、次回にでも・・・

今回は、2/23に JAWS DAYS 2019 に行ってきたので、ちょっとブログにでも。

JAWS DAYS 2019って何よ？

AWSのユーザーグループであるJAWS-UGのイベント。 AWSを使用したいろいろなセッションがたくさんあるよ！！

何の話聞いてきたの？

主にDB周りの話と、今の仕事に関連する話を聞いてきた感じ。 時系列で、Twitterの内容をベースに補完して書いていきます。

メディアによるAI活用（時事クイズの生成と高校野球戦評記事の自動生成）

メディアでのAIが気になったので、ちょっと聞いてみた。

米朝首脳会談の米朝を落語家で類義語にしてしまったやつ

内容的にはIT企業の名前が並んでほしかったけれど。。。
これはソフトバンクをクイズの答えとしてしまったから仕方ない気もする。

記者さんの記事を並べて見てもよくわからないレベルでびっくり。 ここまでAIの自動生成でやれるんだ・・・

機械学習を自動生成で活用しようと思うと、ある程度のテンプレートをベースにどのテンプレートを使うかを機械学習で判断させる感じ。

RDBリファクタリングと異種間DB移行の戦い – Amazon DMSを使った止めずにリファクタリングする手法

DB移行の話で、元々聞きたいと思っていた内容。

テーブル分割を実際に行っていくときにタイミングをトリガー設定。
そういえばそんなことできたなぁ・・・と思い出したやつ。

今回の話として、MySQLからPostgresに移行。
この理由が、トリガーの設定個数を考えたときに、MySQLだとトリガー1個しか設定できなくて１SQLで２つのupdateをなんとかするつらみ。
Postgresの複数個設定できるならPostgresでやればいいじゃんって発想。

DMSって内容柄、論理かつ非同期レプリケーションで扱うのすごい怖いな・・・と思っていたので、どうやって使ったのかすごい気になるゆいな。

どのDBを見るようにするかをうまくAPI化して切り出したから非同期レプリケーションでも気にならないようにできたのねと納得。

そしてMySQLあるあるな治安の悪いデータzerodate('0000-00-00')
postgresに入れたときにエラー起こすんですよねこれ・・・

zerodate以外も想定外データは移行なら出るのはあり得るので、その部分は監視しつつ直していく。

EC2からKubernetesへの移行をセキュリティ/モニタリングから考える

freeeさんのセッション。

freeeさんの場合、匿名化が難しい画像データを持つ必要な出てくるので私からするとガクブル・・・。

止められる場所で事前に止める。セキュリティ的には一般的な考え方ですね・・・。

freeeさんの場合、EC2運用ではWAF,DeepSecurity,GuardDutyで検知させているみたい。

この後のk8s部分はよくわからなすぎてメモも取れてません・・・。

数十億レコードのRDS MySQL5.6を1週間程でAurora MySQL5.7へ移行した時の話

DMSの話ではなかったけどね！！！！！

サービスの内容柄、絵文字を保持する必要があるけれど、DMSでdumpすると、絵文字がつぶれてしまう。 後になって絵文字周りの4バイト文字も問題なく抜けるようになったようです。

最初はmysqldumpでやろうとしていたが、遅いので構成とデータは別で移行する動き。 データはselectして取得したデータをspritしてファイル化。古典的な方法だけれど、ある意味安定してやれそう。

今回の移行はスキーマ統合も必要。またDB依存のダウンタイムを少なくするためのレプリカを使用した3段階レプリケーション。

間違いない。

医療ビッグデータをAWSとオンプレ基幹システムで共存運用

完全にお仕事周りの話だったので聞いてきました。

現在だと医療情報を扱うために３省３ガイドラインがあり、それをAWSでどう解釈するか書いてある感じ。

日本の医療情報ガイドライン

  • 医療データのクラウド化を進めるために・・・
    • 監査のために医療データとそれ以外の情報を明確に分けておく
      • クラウドを誤解している取引先がどうしても多い。そのため物理的なデータセンターの監査をやりたがるため。
    • 匿名加工済みデータはS3へ→データレイク構築

    • Direct Connectで直接S3に置く動きをしている。 →データはネットワークに出さない。

    • データレイク f:id:yu1056y:20190227004412j:plain

      • Glue f:id:yu1056y:20190227004420j:plain
        • Athena,Redshift
        • クローラー未使用
        • Job→Parquet 分割数でのパフォーマンスに偏りが出ることがある。

    • RedShift f:id:yu1056y:20190227004426j:plain

      • looker(BI)→傷病分類等をわかりやすくする

    f:id:yu1056y:20190227004428j:plain insightwatchでセキュリティ周りをやっている →項目の取扱ポリシーが怪しいから適宜有効無効を切り替える。

完全にお仕事モードでTwitter書く暇なかったんや・・・

我々はこうして「AWS本」を書いた！ 〜十人十色〜

AWSの本を書いている方々のパネルセッション。

すいません最近便秘気味で・・・

クラメソのブログを書いていた方のマサカリ対処法が慣れだったのはびっくり。
でも、そういうもんなのかなとも思う。

どうだった？

とても刺激を貰えました。
今まで大きな技術系イベントも行けていなかったので、それを考えると新たな体験ばかり。

私弱いなぁ・・・。もっと強くなりたいなぁ・・・。

機運がすごく高まってやりたくて仕方がないので、どうやってやろうか考えてます。 多分初回は４月かな。会場をどうしようかとかいろいろ。