ヤサイブログ

徒然と

AWS Summit Tokyo 2017に行ってきました。

f:id:yasay:20170604220500j:plain:w350
5月30日(火) ~ 6月2日(金)に行われたAWS Summitに参加してきました。
日本で行われるAWSイベントの中では最も大きな規模です。
www.awssummit.tokyo

場所は品川プリンスホテルで行われました。
f:id:yasay:20170604221009j:plain
↑飛天の間の噴水にそびえるAWSロゴ
AWSさん、どんだけ凝ってるんですかw

今回、私は業務の合間にDay2の午前とDay3の午後に参加してきましたので、
以下にレポートを書いていきます。

5/31 (Day 2)

基調講演レポート

f:id:yasay:20170604230321j:plain

  • 基調講演①
    • 16分野のコンピテンシーというのがあるので、これに沿ってAWSの分野を学習していけばいいかも。
    • Enterprise JAWS-UGというものもあるらしい。

  • アップデートトピック①
    • 日本準拠法を選択可能に
    • 支払い通過を日本円で請求できるように
    • サービスコンソールの完全日本語化を目指す。

  • Digital/IT Transformationの流れが日本にもきている。

  • Digital/IT Transformationの紹介:UFJの例
    • ビジネス基盤を強化することについて
      • 設定の素早さ+経営の俊敏さが要求される

  • 基調講演②
    • 画像認識を使ってルービックキューブをミリ秒で解く動画がとても面白かった。
      • ↓例えばこんなの

www.youtube.com

  • アップデートトピック②
    • Lightsail 本日より東京で使用可能に。
    • PostgreSQL Aurora
      • オープンなデータベースが復旧してきていることは、確かに実感できる。
      • Oracleに追いついてきた感。
      • PostgreSQL AuroraのパフォーマンスはMAX2倍

  • Digital/IT Transformationの紹介:EPSONの例
    • Oracleのラックで動いていたんだが、データベースが高トラフィックだった。
      • これをどうにかしなきゃいけない。
      • そこで選んだのがAurora。全面的にMySQLを採用。

    • 可用性の心配→Auroraは止まらないよね?→やってみないと分からない。
    • 結果、運用工数0→DBAの作業を開発チームに移管可能に
      • ライセンス費用0
      • 障害0!すごい!

  • Digital/IT Transformationの紹介:レコチョクの例
    • VRの取り組みいいね。
      • 配信方法や端末負荷、画質・音質の問題など課題はある。
      • スマホ向けVR映像を横展開とか、VRライブ映像をお届けとか。
      • 世界中に配信環境を提供するためにはどうすればいいのかとか。

  • 基調講演③

  • IOT→クラウドがないと実現が難しい?
    • 意味のあるIOTを実践→ホームセンターのGooDayもIOTやってる(すごいなーw)

  • アップデートトピック③
    • パリ、中国(地名忘れた)、ストックホルムにリージョンを追加予定。
      • リージョンは物理的な拠点。
    • Osaka Local Regionを解説予定
      • 特定の顧客に限定したローカルリージョン

6/1 (Day 3)

AWSで実現するセキュリティ・オートメーション」レポート

  • セキュリティオートメーションという言葉を聞いたことがあるか?→ない
  • なぜクラウドを使わないかアンケート取った
    • →一番の理由はセキュリティ
  • なぜクラウドに移行したのかアンケート取った
    • →一番の理由はセキュリティ
  • セッションのポイント
    • オートメーションは戦略策定の礎
    • セキュリティ・オートメーションを前提に設計されたAWSサービス
    • セキュリティ戦略基盤となるAWSクラウド環境

オートメーションは戦略策定の礎

  • 「やること」と「やらないこと」を決められる = 戦略
    • 多種多様なデータ集約→可視化と効果測定→分析による意思決定
    • →この土台になっているのがオートメーション

セキュリティ・オートメーションを前提に設計されたAWSサービス
  • 対策主体
  • 対策対象
  • 対策場所

  • 防御
    • →SG, NACL, WAF, CloudFront
  • 検知
    • VPC flow logs, Auto Scaling
  • 予測
  • 対応
  • 監視
    • →CloudWatch, CloudTrail

  • IPリストに反映されていない悪いIPを遮断する対策が必要
    • →オートスケールによるトラフィック分散による問題の抑制(吸収)
    • →スケーリングイベントの通知をAmazon SNS
    • →イベント通知をきっかけでLambdaを起動しセキュリティ評価を実行
    • Amazon InspectorのAPIをキックして、脆弱性診断
    • →診断結果をSNSに通知→Lambda起動してNACL/SGのポートブロックによる端末隔離
    • VPC Flow Logsにブロックログを残す。→EC2インスタンスの状態をS3に保存する
    • →CloudTrailにバックアップログ保存
セキュリティ戦略基盤となるAWSクラウド環境
  • AWSインフラ全体のログ取得が可能
    • アクセスログ、S3のアクセス、API操作のログ
    • →オンプレミスだと意外に大変だよね。AWSなら標準で提供されている。

  • 可視化
    • VPC Flow LogsとAmazon Elasticsearch Service/Kibanaによるセキュリティグループの可視化

  • 分析
    • Domain Generation Algorithms
    • CloudFromtのログを見れば、ドメインが分かる。ここでマッチングさせる。
    • AMLで正しいドメインの学習データとして食わせる。
    • AMLの結果を見て、WAFルール更新なんてこともできる。
    • AML起動はLambdaで。ログパーサーAML呼び出し

f:id:yasay:20170604230245j:plain

  • クラスメソッドさんのレポートもおすすめです。

【レポート】AWS で実現するセキュリティ・オートメーション #AWSSummit | Developers.IO

Amazon Aurora (MySQL-compatible edition) Deep Dive」レポート

Deep Dive
  • データベースサービス
    • AWSが一から作ったデータベースエンジン

  • 一番の特徴はストレージ
    • 一から作った
    • SSDを利用したシームレスにスケールするストレージ
    • 10GBから64TBまでシームレスに自動でスケールアップ
    • 標準で高可用性を実現
    • S3に高速にバックアップする仕組みを備えている。

f:id:yasay:20170604230635j:plain

  • ストレージノードクラスタ
    • Protection Group毎に6つのストレージノードを使用
    • 各ログレコードはLog Sequence Numberを持っており、不足・重複しているレコードを判別可能
    • 6つのストレージノードを使用

f:id:yasay:20170604230738j:plain

  • ディスク障害検知と修復
    • 2つのコピーに障害が起こっても、読み書きに影響はない
    • 3つのコピーに障害が発生しても読み込みは可能。

  • IO traffic in Aurora(ストレージノード)
    • 全てのステップは非同期
    • スループットの影響が起きないように作られている。
    • 6本のうち4本からストレージが帰ってくれば問題ない。(2本はあとで保管。)

  • セキュリティ
    • データの暗号化サポート
    • SSLを利用したデータ通信の保護

  • フェイルオーバーとリカバリ
    • リードレプリカがある場合1分ほどでフェイルオーバー可能
    • リードレプリカが存在しない場合10-15分
    • Multi-AZ配置として別AZで起動可能
    • 高速でより予測可能なフェイルオーバー時間
      • クラッシュリカバリの速度が3病から20病で終わるように設計
      • →Auroraがやるんじゃなくてストレージノードが判別してやっているから早い。
    • Auroraのフェイルオーバータイムの内訳は、一瞬で終わるのが30%。
  • Streaming backupとPITR
    • ストレージに書き込まれた瞬間からS3に継続的にかかれていく仕組み。
    • AuroraはそのままログとしてS3に書き込まれる。
    • 何があってもパフォーマンステストをいつしてもBackupを含んだペナルティの性能になっている。

  • 任意の位置で復元可能。
    • 各セグメントは定期的なSnapshotは並列で行われ、redo logはストリームで継続
    • バックアップのためにS3に送られる。パフォーマンスや可用性に対する影響はなし

  • Writer / Readerノートの識別
    • innodb_read_onlyモードでマウントされている。
    • SHOW GLOBAL VARIABLES LIKE 'innodb_readonly'

  • SQLによるフェイルオーバーのテスト
    • SQLによりノード・ディスク・ネットワーク障害をシミュレーション可能
    • ディスク障害、ディスクコンジェスションをシミュレーションが可能
    • →これらSQLはAuroraのみに実装されているクエリ

  • Aurora Driver
    • MariaDB Connector/JにFast failover Auto node discoveryが実装されているので、このDriverを使ってみてほしいとのこと。
      • Fail Over時間が短縮されるよ。
  • パフォーマンスTips
    • Auroraのパフォーマンスは圧倒的
    • チューニング設計
      • MySQLのチューニング戦略がそのまま適用できる。
      • Auroraはマシンリソースを最大限使うような設計になっている。
      • CPU、スループットなど、CloudWatchで監視して確認してほしい。
    • まずはデフォルトのパラメータグループ使用を推奨?。
    • トランザクションで大量の更新や削除を行ったり、大量データのシーケンシャルリードを行う場合、区切れる単位でSQLを分割して並列で投げてくれると、性能が上がりやすい。

f:id:yasay:20170604230935j:plain

  • 拡張モニタリング
    • Elastic Service連携も可能

  • Auroraへの移行は?
    • InnoDBのみサポートしているので、マイグレーション時に自動でコンバートされるが、手動で対応ストレージエンジンに変換しておくのがよい。

  • RDSからの移行は、
    • Aurora Read Replicaを自動生成する機能があるので、最新のデータによる移行が可能。

  • Percona Xtrabackupを利用してAuroraへ移行可能
    • mysqldumpと比較したテストで20倍高速に移行可能

改善を行ってきた機能(前回のサミットから追加された機能の一部を紹介)
  • Reader Endpoint
    • →ロードバランサみたいなエンドポイントがあって、ラウンドロビンで振り分けられる。
    • →Readerが一瞬でも消えた場合はフェイルバックが起こり、Writerを指す場合がある。

  • IAM Authentication Integration
    • Amazon Auroraへログインするための認証にIAMが利用可能に
    • →credentialを配布する必要がないので、開発だけアクセスできる本番だけアクセスできるような使い方が可能。
    • IAMポリシーで矯正が可能?

  • Lambda Function Integration
    • ストアド・プロシージャとして実行

  • Load Data From S3
    • S3バケットに保存されたデータを直接Auroraにインポート可能
    • テキスト形式、XML形式

  • 空間インデックスサポート
    • Auroraに入れる時に性能の改善が行われているので、ベンチマークで2倍の性能差が出てる。
    • インデックスの持ち方を変えたことで、性能向上。
    • 同じメソッド、関数を持っているけど内部的にはインデックスの持ち方が変わっている。

f:id:yasay:20170604231007j:plain

  • 監査の機能
    • Aurora native audit supportは15%程度の性能ダウンでいける。
    • ログファイルに出力するところを、パラレルに書き込むできるようにすることで、性能を向上させた。
    • mariadb server_audit pluginとの比較です。

  • Zero downtime patch(ZDP)
    • コネクションを切断することなくオンラインでパッチを適用できる
    • 5秒程度スループットの低下が起こるが、接続を維持したままパッチを適用可能に。
    • ベストエフォートなので、この機能を期待してアプリを作るのはやめたほうがいい。

f:id:yasay:20170604231050j:plain

  • 性能面
    • Cached read performanceの改善
    • →性能はどんどん挙がっている。
    • Insert Performance→地道なパフォーマンス改善を続けている。

f:id:yasay:20170604231212j:plain

  • Fasted Index build

  • Lab Modeがある。
    • FAST DDL
      • add columnが1秒もかからない処理になる

さらなる改善に向けて
  • データベースバックトラック
    • オペミスの内容を一瞬で特定の状態に戻す機能
    • データは残っているんだけど、シーケンスNo的なものを巻き戻すことで、戻す
    • 超高速に巻き戻す
    • →バックアップから別のクラスを立ち上げるのではないので、リカバリが早い。

  • Databse cloning
    • ストレージコストを増やすことなくデータベースのコピーを作成
    • 1分か2分くらいでCloningできる。
    • その↑にインスタンスを立てればいい。
    • 料金はコピーしただけだとストレージ料金はかからない。
    • cloneに書きこんだ分の料金はかかるかも?。

  • Auroraは高いクエリ実行並列度、データサイズが大きい環境で性能を発揮
  • コネクション数やテーブル数が多い環境で優位

  • AuroraとRDSでパフォーマンステストをして、試してほしい。
  • データの堅牢性はAuroraに軍配。

「【AWS Tech 再演】AWS のコンテナ管理入門(Amazon EC2 Container Service)」レポート

なぜコンテナなのか
  • DevOpsのために再発見された
  • 開発に専念したい→インフラの運用管理を効率化した
  • 可搬性→不変なイメージ
  • イメージを本番環境にそのままリリースできるのっていいよね。
  • 柔軟性、速度

  • ベスト・プラクティス
    • アプリをコンテナに適応させる(12 factor apps)
    • 複雑さを避ける→シンプルに保つ

  • タスクに集中する
    • タスク = ジョブの単位

  • そこで登場する課題:クラスタ管理
    • 1台のサーバ上でコンテナを扱うのは簡単
    • 複数ホスト上でのコンテナ管理は非常に難しい
    • アプリケーションの開発に専念したいはず

Amazon EC2 Container Service 概要
  • メリット
    • 簡単に、どんなスケールのクラスタも管理できる
    • 状態管理、操作、監視、スケーラブル
    • 柔軟なコンテナの配置
      • アプリケーション、バッチジョブ、複数のスケジューラ
    • 他のAWSサービとの連携がデザインされている
    • 拡張性の高さ -> 分かりやすいAPI

f:id:yasay:20170604231315j:plain

  • コンテナ
    • ECS AGENT
    • MANAGER
      • CLUSTERのリソースとTASKの状態を管理
      • 変化を追跡
    • TASK DEFINITIONS
      • コンテナ情報とボリューム情報に分割

  • Task
    • コンテナ実行の1単位
    • 関連するコンテナでグループされる

  • スケジューラ
    • Run Task←バッチに最適
    • Service←Web/APIに最適


クラスタに対してマネージャーを介してスケジューラからタスク定義的な

  • クラスメソッドさんのレポートもおすすめです。

【レポート】AWS Summit Tokyo 2017:AWS のコンテナ管理入門(Amazon EC2 Conatainer Service) #AWSSummit | Developers.IO

「【AWS Tech 再演】Machine Learning on AWS」レポート

  • 解決したいビジネス課題から出発したほうがいい。
  • ツールなので、それ自体を使うことが目的ではない。
    • もっとシンプルで簡単なやり方のほうがいいということはよくある。
    • それでも上手くいかないケースで活用するべき

  • 大量の良質なデータでモデルの精度が向上
    • →(良質なデータが)継続的に手に入るかどうかが重要
  • 判断や予測を自動化することが可能
    • →自動化する価値のあるクリティカルな予測か?
  • 大規模に展開するほどコストが下がる
    • →費用対効果に見合うか?

  • AI Engines
    • インストールがものすごくめんどくさい
    • AMIイメージで簡単に利用できる
    • MXNetを全面的にサポート
      • →スケーラビリティに優れている。

  • AI Platform
    • AML マネージドサービス
    • EMR

  • AI Service
    • アプリケーションサービス
    • Right tools for the job
    • Managed services first

  • ゴールを明確にする
    • モデル
    • トレーニング
    • 予測

  • クラスメソッドさんのレポートもおすすめです。

【レポート】AWS Summit Tokyo 2017: Machine Learning on AWS #AWSSummit | Developers.IO

参加した感想

私は今回AWS Summitに参加するのは初めてだったのですが、
その圧倒的なイベント規模に驚かされるばかりでした。
ユーザイベント規模ではなし得ないことばかりです。
AWSがお金持っているということなんでしょうけどw

タイミングがいいのか悪いのか夏日並みの気温だったので、
品川プリンスホテルまでの道中が暑いこと・・
会場の人の多さにも圧倒され気疲れが大きかったです。

この雰囲気の中1日中勉強のためにTechトラックを見るのは
かなり大変なんじゃないでしょうか。幸いなことに1トラック40分なので
集中力は持続できると思いますが。

私は今回Day2の午前中とDay3の午後のみ参加したので、
丸一日いたら普段の業務よりしんどかったんじゃないかとw

もちろん、Techトラックで勉強した収穫は大きいので、
参加できたことには大きな意味がありました。

ランチが出る無料の大規模イベントがあるらしい(It's AWS Summit 2017 Tokyo!)

f:id:yasay:20170604230427j:plain
カツサンドうまかったです。ありがとうございます。

認定者ラウンジで傘を頂きました。ありがとうございます。

f:id:yasay:20170604224415j:plain
もったいなくて使えないですわ・・

一時の癒やし:品川プリンスホテルの日本庭園

f:id:yasay:20170604222416j:plain
来年も日本庭園を拝めますように・・

晩御飯:一日分の野菜が採れるカレー

f:id:yasay:20170604222820j:plain
一日分の野菜って思った以上に量が多いw
栄養バランスを取るって大変ですね・・

AWSおみくじ(by クラスメソッド様)

f:id:yasay:20170604222859j:plain
Athena使うぜ!うひょー!

以上、レポート&感想でした!
参加した皆さん、お疲れ様でした!

JJUG CCC 2017 Springに行ってきました。

f:id:yasay:20170601095510j:plain:w350
今年もきたぜ、JJUG CCC。
去年のFallはボランティアとして参加しました。
今年はがっつりセッションを聞きたいので一般参加です!

このエントリーの体裁を整えている時に、
AWS Summit 2017 Tokyoに参加していました。
ベントラッシュと業務で忙しいこの頃、皆さんお元気ですか。
7月1日はDevelopers IOに参加したいとも思っています。
classmethod.jp

最近ブログのエントリーが遅れがちなことについて

(コーディングの)アウトプットを最近優先しています。
ですので、インプットの内容をブログに残すことが
遅れがちになっていると思います。
ですので、行ってきたレポートはなるべく
その場で書いていき、スピードを上げていきたいと思います。

今回の内容は試しに、が重要なインプット、を所感で記述してます。

レポート

非機能要件とSpring Boot

speakerdeck.com

  • 「機能要件」以外の要件が「非機能要件」
  • 「非機能要求グレード」←IPAの資料がまとめられていて便利

  • Spring Boot Actuator → 運用・保守性に貢献
    • 運用監視、活性保守
    • JSonViewプラグインなどで整形すると見やすい
    • 運用中のログレベルの変更が可能なのはすごく便利だなぁ。最高じゃん。→でもこれActuatorが必要なの?
    • メモリは圧迫するかも
    • pull型基盤なので、自分からデータを取り出すような仕組み

  • Spring Security & Others
    • PassayというパスワードポリシーをBeanValidationで使うのが便利らしい。
    • SHA*ではなくBcryptまたはScryptを使うべきなのかー!
    • jasyptでプロパティファイルを暗号化することもできるのか。本当に勉強になる。
    • 復号化のキーは環境変数などに隠しておく。これはいいな!

  • Spring Data JPAによる監査ログ便利だなー。
    • Spring Securityのログイン情報を登録することができるんだな!
    • JPAの@MappedSuperclassも忘れずに覚えておこう。


IPAの非機能要件グレードは参考になりすぎた。
業務でも活用していきます!

www.ipa.go.jp

Vue + Spring Bootで楽しくフルスタック開発やってみた

Vue.js + Spring Bootで楽しくフルスタック開発やってみた

  • 登壇者が担当した業務の要件
    • AndroidiOSの両方に対応する
    • 機能的にはWebアプリの域を脱しない
    • なのでCordovaを選択→Webビューを使ったフレームワーク

  • Vue.jsを使うと双方向バインディングができる。
    • ネイティブアプリっぽさを出すためにSPAを目指した
    • vue-router 2 → ルーティング
    • Vudex → Flux実装 → SPAで、状態を保持するのにかなり便利だったらしい。
    • axios → HTTPクライアント → ajaxの機能のため

  • npmとwebpackの導入
    • npm → JavaでいうMavenやGradle
    • webpack → build.jsを生成するためのツール的な。プラガブルなコンパイラ
    • webpack dev serverが便利らしい。 → コード変更を検知してビルドや、ブラウザの自動リロードなど。

  • Vueの便利なもの:Chrome拡張
    • Virtual DOMの状態や、バインドされている値を確認できたりするので便利。使うべし。

CSS Grid Layoutはかなりすごいらしいので、触ってみたい。
spring boot devtoolsとwebpack dev toolsでのHot Reloadingな開発面白そう!

Javaエンジニアに知って欲しいRDBアンチパターン

  • データベースの寿命はアプリケーションより長い。

  • アンチパターン2:
    • memo, memo2, memo3
      • 不適切な名前ではデータベースのテーブルの関連性や意図が理解できない。

  • アンチパターン3:
    • 論理ID(途中2桁は都道府県コードを表すような例) → データにロジック埋め込むな。
    • アプリケーションを変えずにRDBのトリガという機能を用いて移行させることができる。
    • 理想のViewを作って、参照はこっちとか進めていく。

  • アンチパターン4:強すぎる制約
    • 変更が大変→時間が経てば立つほど状況が悪化
    • データベースほっておいても直らない。
    • そのためにRDBの機能を活用する。→ しかしそれが裏目に出ることも。
    • RDBの機能に依存しすぎると裏目になることがある。
    • (※ストアドは更新する時にデータベースの停止が必要になる! -> だからあまりストアドにロジックを持ちすぎないほうがいい。)
    • 成功体験のバイアスや、失敗体験のバイアスが、最適な手法の選定を妨げる。正しい設計を学ぶ方法とは?

  • 一度作ったDBは消せない → だからこそ設計が大事
    • データベースの死はサービスの死 → 解決できる人は英雄

  • DBの問題は忘れた頃にやってくる。
  • サーバーの問題は休日にやってくる。
  • アプリケーションの問題は納期前にやってくる。
  • 脆弱性の発見は連休中にやってくる<- New!!


SQLアンチパターンを読むことを登壇者の方がおすすめしていたので、
読みたい。会社にあった!

www.oreilly.co.jp

Introduction of Project Jigsaw

www.slideshare.net
f:id:yasay:20170601105602j:plain

  • Moduleに依存性と公開範囲を書いていく。
    • メタ情報があるのがModule.それ以外がjar。
    • module-info.javamavenみたいにがんがん書いていく。

  • 依存性

module net.jitb.hello {
// 依存性の追記
requires javafx.controls;
}

  • 公開範囲

// puckage export
exports net.jitb.hello;

  • 新しいものを作るのは簡単。
    • 古いものを混ぜるのは大変。
    • export書かないと、publicにならない。
    • なので、java9で使えなくなったライブラリがある。
    • class.getInstanceとか。

  • javaコマンドに、--オプションがたくさん増えた。
    • ※javac生で打つことはほぼないよね。
    • IntelliJ IDEAは既にJava9に対応している。

execution( --module-path mod ~

  • 標準モジュールの確認
    • java --list-modules 現在73個くらいらしい
    • java., jdk., javafx.ではじまるものがある。java.で始まるものが使えるもの。

  • カスタムJRE
    • jlinkを使って自分が欲しいモジュールだけを定義できる。
    • 自分が持ってるモジュールもパッケージング化してカスタムJREの作成ができる。

  • マイグレーションをどうするか
    • ただのJarファイルをモジュールにしたい場合に、ライブラリが何に依存しているかをjdepsコマンドで確認できる。

  • Automatic Module
    • モジュールパスに置くだけで、Automatic Moduleとして扱ってくれる。


JigSawはJava9リリースまでに変わる可能性がまだまだあるので、
今後の動向を見張っておく必要があります。
個人的には依存性が分かりやすくなるのは便利だと思うので大変興味があります。

Engineers can change the world ~ "世界"で活躍するエンジニアになるために

f:id:yasay:20170601105707j:plain
docs.com

  • 自分の中に本能的に発生している差別(血液型や性格などで人を判断するような偏見)というのはよくない。
    • それが、"my unconscious bias"(自分の無意識の偏見)

  • 登壇者の方は、富士ソフトABC→SUN→OracleMicrosoftというすごい経歴を持つ人。
    • 中学時代とか、高校時代とかに英語は全くダメだったらしい。
    • 逆に日本語の文章を翻訳して見ている外国のエンジニアだっている。
    • 今は自分たちが思っている以上にグローバル化している。

  • 39歳でJavaを作った生みの親を見れば、35歳定年説なんて関係ない!というかありえない。
    • 学び続ける姿勢が大事
    • クリント・シャンク
    • 年齢関係ない
    • やはり英語は重要。

  • 自分が持っているバイアスをいかに取り除くか。
    • そうすれば、もっと他人と話しやすくなる。みんなをリスペクトしていく姿勢が大事。

  • 目が不自由なマイクロソフトエンジニアの話がすごい。感動した。
    • これを見ると、本当にITが世界を変えると思える。

www.youtube.com

  • love your self
  • love your peers
  • love your work
  • 自分を変えられのは自分だけ。

  • inputが多い人はアウトプットをしていこう。
    • ブログやSNSから、登壇へ。
    • OSSへのコントリビューションだったり。
    • 日本人であっても世界で活躍できる場所は、たくさんある。
    • 夢は必ず叶います。
    • 夢を持って成長すれば、世界は決して遠くないと思う。

  • embrace community
  • embrace diversity
  • embrace inclusion

ハックで生きる:オープンソースで会社を興すには

www.slideshare.net

  • オープンソースのビジネスモデル
    • プロフェッショナル・サービス
      • 正しい使い方の指南
      • 個別企業向けに追加機能の請負開発\
    • 製品版
      • 作れば勝手に売れるものではない。
      • OSS版で十分だと思っている人が大半。
      • 企業のサイズ、ポジショニング、営業が必要

  • SaaS
    • 価値の上限や、顧客個別事情への対応など

  • サポート
    • それなりの体制・規模・仕組みが必要
    • 知識のある技術者を雇わないといけない

  • コミュニティから人を雇える魅力がある。
    • 優秀な雇うべき人を探すのは簡単
    • 働き方も癖も性格もわかっている

  • OSSの貢献にも限界が
    • 趣味の細切れの時間や本業の片割れの時間で出来ることには限界がある
    • 複数のコミュニティ開発者が共同作業するのは難しい
    • 時々即売上になる?→おまけとして引き抜き前の会社から売上もらうとか(笑)

  • 欠点もある、
    • 開発者の中に葛藤が。
    • 自分の時間?仕事の時間?
    • 会社がやりたいことと、自分がやりたいこと

  • プロジェクトを横取りしようとしていると映る危険性?
    • 主要開発者がみな同じ会社の従業員になってしまったら?

  • プロジェクトの開発者が目減りする
    • 製品開発に回ってもらうとその分OSSに穴ができる

  • ブランド・商標・法律関係
    • 商標が誰のものになっているのか、確認が大事
      • 昔HUDSON問題とかもあった。

  • お金持ちになりたいんだったら、オープンソースの会社なんか作っちゃいけない😁
  • オープンソースは無双
  • 開発手法が最強
  • 組織が力を結集しないとできないこともある。
    • 一人でできる仕事と一人ではできない仕事との違い。
    • 開発者だけでは実現できない仕事。

  • 企業の参加で初めて得られるリーチがある。
    • 他の企業の参加も促せる。

  • Blue Oceanすげぇ!


結構ぶっちゃけ話が多かった気がしますが(笑)。その度に笑いをさそってました。
Jenkins生みの親の方が登壇していたこともあり、その一つ一つの言葉に説得力がありました。

個人的に見たかったセッション

Javaで実践して学ぶOAuth2.0!

speakerdeck.com

コーヒーカップワロタw

f:id:yasay:20170601100159j:plain
Google I/O 2017でKotlinがAndroidの開発言語として公式にサポートされるようになって、
自称エヴァンジェリストの方が調子に乗っているようですw
こういうの好きw

懇親会で回転寿司が出たw

f:id:yasay:20170601105737j:plain
無料で参加できるイベント(もちろん懇親会も)で
寿司が出るイベントというのはなかなか、ないですよね!
スポンサーのLINE様に感謝したいところです。
あっという間に売り切れてステッカーが回っていた模様w

成子天神社

f:id:yasay:20170601105811j:plain
ベルサール新宿のすぐ近くにある神社。相変わらずピンキーなピンク色してるなw
冬にまた来るから、その時にまた拝みにきたいと思います!


以上、JJUG CCC 2017 Springのレポートでした!
参加者の皆さん、お疲れ様でした!

(AWS)AWS SDKを使用してS3にファイルをアップロードする際に、Content-Typeを指定する

自分用の備忘録です。
ObjectMetadaクラスを使用することで、
S3へアップロードするファイルにメタデータを指定できる。
画像ファイルに"image/png"などのContent-Typeを指定したい場合に
メタデータ指定を利用する。
正しいContent-Typeを指定しないとブラウザが
おかしな判定しちゃう時があるらしい。

プログラミング言語 Java 8
AWS SDK Version 1.11.89

(AWS)EC2のWebApplicationからS3の署名付きURLを取得する方法

自分用の備忘録です。
EC2からS3バケットの画像ファイルなどを取得したい時に便利。
バケットポリシーを変更することなくアクセスできる♪

プログラミング言語 Java 8
AWS SDK Version 1.11.89

「AWS認定ソリューションアーキテクト-アソシエイトレベル試験」に合格したよ!

AWS認定ソリューションアーキテクト-アソシエイトレベル試験に合格しました!
aws.amazon.com

試験を受けた動機

2017年の調査会社による報告によれば、
クラウドインフラ市場の3割以上のシェアを占めているらしい
Amazon Web Services

そんなAWSに魅力を感じられずにはいられません。
なので私はより深くAWSを理解するためにも、
認定試験に合格することを目標にAWSの知識を深めました。

受験までを振り返る。どんな勉強をしてきたか。

勉強した内容を書いていきます。

実務による開発経験を積みました。

2017年1月から3ヶ月間、AWSを用いたウェブアプリケーション開発をひたすら
行っておりました。実務経験により様々なAWSサービスを利用できましたが、
この経験は次に受ける「デベロッパー-アソシエイト」で
主に役に立つと思います。

Blackbeltのオンラインセミナーの資料を全て読みました。

今思えば、試験範囲の内容に絞って見ておけばよかったのですが、
160近くあるドキュメント全てに目を通したことにより
試験範囲外のAWSサービスまで理解できたのでまぁよしとします!

ホワイトペーパーを読みました。

BluePrintに記載があるホワイトペーパーを探すのは面倒でした。
リンクをまとめてくれると助かる。なので下記にまとめます。↓
リンク切れになる可能性があります。ご了承下さい。

■アマゾン ウェブ サービスの概要

https://media.amazonwebservices.com/jp/wp/AWS_Overview.pdf

■障害復旧を目的としたAWSの使用

https://media.amazonwebservices.com/jp/AWS_Disaster_Recovery_01242012.pdf

上記ドキュメントは付録を覗いて全て読了しましたが、
正直かなりキツかった。特にセキュリティプロセスの概要が80ページ程あり、
内容も濃いので気合を入れて読むことをオススメします・・。

サンプル問題を解く

基本的に後述するWEB問題集や模擬試験を含め、
間違った箇所の再学習が重要です。

WEB問題集のフリープランで腕試し

AWS WEB問題集で学習しよう – 赤本ではなく黒本の問題集から学習する方向け
独自の問題集らしいのですが、内容的には模擬試験にかなり似ています。
ただ、あまりこのサイトを頼らないほうがいいと思います。
なぜならば、ソリューションアーキテクト-アソシエイトレベルの内容は
充実していますが、他のレベルの内容は足りていないからです。
問題の雰囲気を掴む程度に利用したほうがいいと思います。

模擬試験を受けました。模擬試験の結果は合格!

模擬試験は有料ですが、試験に合格したいのなら
受けるべきです。模擬試験は自宅で受けることができるので
問題のコピーも可能です。回答は表示されないので、
どこを間違ったのか自力で調べて、回答を導き出す必要があります。
自分は模擬試験は合格しました!

そして本試験!結果は合格!

本試験は試験会場で行われます。
模擬試験と比べて難易度が高く、
受験料も高いので慌てそうになりますが、冷静に問題を解いていきます。
無事に合格できました。

個人的に、認定試験を受けるなら抑えておきたいAWSナレッジを共有します。

Active Directoryを活用したAWS Management ConsoleへのSSO(AD Connector編)

Active Directory関連は抑えておいたほうがいいと思います。
特にAD Connectorが何なのかとか。
dev.classmethod.jp

プレイスメントグループ

プレイスメントグループは個人的に影が薄くて忘れていた存在!(ぉぃ
認定試験ではとても重要な内容です。完全に理解しておくことをオススメします。
docs.aws.amazon.com
dev.classmethod.jp

CloudFormationでStackを削除した時にリソースを消さない設定

こんなのCloudFormation使ってないと絶対分からん!的な内容。
これまた、認定試験では重要な内容です。
dev.classmethod.jp

S3への保存に成功したことを確認する方法とは

MD5チェックサムを確認する方法を抑えておいたほうがいいと思います。
qiita.com

EC2セキュリティグループの反映タイミング

EC2クラシックとVPC内で反映のタイミングが異なるのは理解しておきたい。
即時反映はVPC内のみ。

AWS Summit 2017 Tokyoで確認したところ、両方とも即時反映との回答を頂きました。
docs.aws.amazon.com

OLTPとは何か

このような用語を覚えておかないと、認定試験でつまづきます。
OLTP、OLAP、DWHそれぞれの特徴や違いを把握しておくことをオススメします。
www.imkk.jp
http://www2.gssm.otsuka.tsukuba.ac.jp/staff/kuno/lectures/11/2011-10-InfosysTech2.pdf


次は「認定デベロッパー-アソシエイト」を目指します!
とりあえずAWS Summit 2017 Tokyoに参加する!
www.awssummit.tokyo

Kindle Paperwhite マンガモデルを購入しました。1ヶ月使ってみての感想。

Kindle Paperwhiteを購入して1ヶ月程使ってみたので、
感想を書いていきます!
f:id:yasay:20170507014003j:plain

Kindleに400ページ近くある分厚い技術書を詰め込んで
持ち歩きたかったので、マンガモデルの32GBです。

開封

f:id:yasay:20170507022604j:plain
電子ペーパー端末を初めて購入したので、
開封したばかりの状態で既に何かしら表示されているのを見て、
少し感動しました。

f:id:yasay:20170507022941j:plain
ベゼルはプラスチックなので正直チープですが、
高級感がないから使い倒しやすい気がします。

どんな本を入れているか

マンガモデルですが、マンガは入れてないですw

オライリー技術評論社のWebサイトで購入した電子書籍
自炊した技術書、 勉強会で共有されたスライド資料などを入れています。

WEB+DB Pressは重くてかなり見づらい

gihyoから購入したWEB+DB Pressはファイルサイズが40MB近くあり、
特定のページで激重になり見づらかったです。
対策として目次を使った移動をすればOK。
gihyo.jp
上位の機種だともう少し快適になるのでしょうか?

使ってみて分かった、Kindleのメリット

電子ペーパーはかなり読みやすい。

f:id:yasay:20170507070125j:plain
本体サイズが小さいわりに文字はかなり見やすく、
太陽光を受けた状態での閲覧もすこぶるいいです。
さすが読書のために作られた端末と言えます。

手軽な本体サイズと重量

f:id:yasay:20170507071832j:plain
↑一般的な技術書のサイズと比較した画像
サイズが「169 x 117 x 9.1mm」とかなり小さいサイズで、
重量も「205g」しかありません。
なので、どこにでも持ち歩けます。
このサイズと重量で何百冊と本を持ち歩けることは、
分厚い技術書を読む私には大きなメリットです。

横表示(ランドスケープ)モードがかなり便利。

f:id:yasay:20170507072533j:plain
Slideshareの資料を横モードで閲覧
とても便利な画面の横表示機能。
スライド資料の閲覧時にぴたっと収まってくれます。
文字が小さすぎる書籍なんかも快適に読書できるようになります。

ライトがついているPaperwhiteをおすすめ

暗いところでも読書できるというのは、意外と便利です。
Kindleを購入する際は、Paperwhite以上のモデルをおすすめします。
私はキャンペーン無しモデルを選択しました。

価格も手頃なので、使い倒すつもりでネイキッドでの利用をおすすめ

私はスマホにケースをつける派なのですが、
Kindleにはあえてケースをつけないで持って行きます。
このサイズと重量に大きなアドバンテージがあるので、
アドバンテージを損なう可能性があるケースの着用はしません。
落としたり、色が変わったりして味のあるKindleになってほしいかなw

最大のメリットは「本を読む」ことに集中できること

スマートフォンだと遊んでしまうという話はよく聞きます。
仕方のないことだと思います。スマホはゲームだってできるし、
Youtubeだって見れる。やはりKindleを利用することの最大のメリットは
「本を読む」ことに集中できることだと思っています。
バッテリーも2週間以上持つことが多いので、
電池残量を心配する必要もありません。


以上、1ヶ月使ってみての感想でした!
どうでもいいけどKindleのブラウザはいつまで
体験版なんだろうかw

(AWS)無料ドメインをRoute53で運用してEC2インスタンスに紐付ける

むかしむかしドットコムブームがありましたよね!
懐かしい・・。
さすがにドットコムは無料で取得できませんが、
"gq"などのドメインは無料で取得できます。

今回は、無料ドメインをEC2インスタンスに紐付けてみたいと思います!

本エントリーの画像にあるElastic IPアドレスなどは削除済みです。

Freenomから無料ドメインを取得

無料ドメインを取得します。今回はFreenomから取得。
Freenom - 誰でも利用できる名前

Route 53に取得したドメインを登録する。

f:id:yasay:20170418150845p:plain
TypeはPublic Hosted Zoneを選択

f:id:yasay:20170418151414p:plain
登録すると、NameServerの項が設定される。

EC2にElastic IPを割り当てる

新しいElastic IPを割り当てる

f:id:yasay:20170418151908p:plain

EC2インスタンスに関連付ける

f:id:yasay:20170418152148p:plain

Route 53でAレコードを作成する

f:id:yasay:20170418152831p:plain
ValueにElastic IPを指定する

f:id:yasay:20170418153012p:plain
Aレコードが作成された

Freenomのネームサーバ設定を変更する

Route 53のNSレコードの内容を設定する。
※設定の完了には時間がかかる模様
f:id:yasay:20170418170729p:plain

アクセスしてみる。

f:id:yasay:20170418170457p:plain
アプリケーションサーバにアクセスできました!

ちなみに、Route 53の
料金がかかりますが、微々たるものです。

無料ドメインを使って簡単にサーバを立てられる
いい時代になりましたね!

以上です♪