【テックリンク】「平日の夜1時間で学ぶ!Ruby on Rails初心者ハンズオン」開催しました!

テックリンク_平日の夜1時間で学ぶ_RubyonRails初心者ハンズオン

エンジニア向け勉強、「テックリンク」の第1回「平日の夜1時間で学ぶ!RubyonRails初心者ハンズオン」を、2016/8/19(金)19:00-21:00 株式会社リンクバル本社にて開催いたしました。

講師を勤めさせていただきました、新規サービス開発チーム エンジニア リーダーの中村です。

20名を超える大勢の皆さまにお越しいただきました。ありがとうございました!

どのような勉強会か

概要

「Ruby on Rails初心者ハンズオン」

金曜日の夜にRailsを学ぼう!

WEBサービス開発が容易なRubyonRails、この機会に学んでみませんか? 一緒に学ぶ仲間もできるかもしれません。

複数のrails経験者がサポートします!

参加資格

RubyonRailsを学びたい方なら誰でも参加OKです。

ハンズオン内容

  • Railsを選択するメリット/デメリット
  • 新規事業におけるrailsの導入事例
  • RubyonRails開発環境セットアップ(クラウド利用予定)
  • HelloWorld!
  • scaffoldを利用した開発

タイムテーブル

  • 18時300分 受付開始!
  • 19時00分 railsハンズオン
  • 20時15分 懇親会
  • 21時00分 解散

勉強会スライド

テックリンクとは

人とアイデアで世界をつなぎ社会を幸せにする未来創造企業「リンクバル」が、八丁堀のオフィスで開催するエンジニア向け勉強会です。

勉強会や懇親会を通して、エンジニア同士のつながりを広げて参ります。

リンクバルエンジニアの関心ごと

RoR/objective-c/AWS/React.js/git/AI/チャット/MachineLearning/エンジニア主導の自社サービス

おわりに

テックリンクではこれからも、エンジニアの興味があるテーマに関する勉強会を開催する予定です。

イベント参加ご希望の方、ご登録お待ちしております!

テックリンクの最新情報は、conpassにて発信して行く予定です。

リンクバルはRuby on Railsを使って自社サービスを一緒に開発するエンジニアを積極募集中です。まずは弊社のエンジニアとランチで相互理解を深めるところから始めることも可能ですので、こちらよりご相談くださいませ。よろしくお願い致します!

関連リンク


元オンプレ系インフラエンジニアから見たAWSについて


みなさん初めまして!リンクバルでエンジニアをしている高島です。

私は過去オンプレミスシステム(以降オンプレ)のインフラ部分の設計・構築・運用に携わってきましたが、リンクバルではパブリッククラウドの最大手Amazon Web Serviceを利用して各種サービスを運用しています。
オンプレとクラウドのメリ・デメ比較については多くの技術サイトで語りつくされていると思いますのでそちらにお任せし、ここでは元オンプレ系インフラエンジニアの目線から衝撃を受けた点を挙げていきたいと思います。

(1)サーバ立ち上げまでのセットアップ時間が10分以内!!

AWSのコンソールからEC2の立ち上げを行うのに必要な時間は10分以内(!!)です。
これはずっとメディアからOSをインストールする環境で仕事をしてきた者としては驚異的でした。
オンプレでもVMWare、Hyper-Vなどの仮想化技術を利用し一度作成したイメージから2台目以降を複成することは可能ですがAWSでは用意されたAmazonマシンイメージ(以降AMI)を利用することで1台目から素早く立ち上げることが可能です。
また、このAMIはAmazon以外にも各社・各団体も提供しており無数に存在します。
これらを柔軟に利用することで非常にすばやくシステムの立ち上げが可能です。

(2)HWをまったく意識せず構成が可能

AWSに限らず、クラウドコンピューティングでは物理的なHWが隠蔽され、利用者側は全く意識することなく必要なリソースを必要なだけ借りられるというメリットがあります。
オンプレでも複数のサーバHWを共有ストレージに繋ぎこみ、仮想化技術を持ちいてHW間のノード移動させることは可能ですが、オンプレはあくまで手元にあるHWの制約を受けるためクラウドに対し柔軟性が劣ります。
また、AWSでは作成したAMIやスナップショットを同一AZ内において自由に扱うことが可能です。
これはテープ装置やストレージ間レプリケーションを用いてバックアップ・復旧の運用設計をしてきた者としては非常に素晴らしい仕組みと感じました。

(3)IOPSに対しての課金

AWSではストレージ、NW、ロードバランサなどで発生するIOPSに対して課金が発生します。
また、デフォルトの帯域に不満があればコストを掛けることで増強することが可能です。
オンプレでDBサーバやバッチサーバのIOPS周りの速度に頭を悩まされてきた者としてはこの仕組みは衝撃的でした。
コストを掛けただけ性能が上げられる仕組みのため、柔軟性が非常に高いと思います。
ただし、オンプレのように手元にある機器を好きなだけ使えるわけではなく、使った分がコストになるため思考の転換が必要となります。

まだまた語りつくせないところではありますが、今回はここまでとさせていただきます。
ここまで読んでいただきありがとうございました!

リンクバルではクラウドの経験が浅い人でもさまざまな経験を経ることでスキル習得が可能です。
オンプレミス環境が恋しい気持ちもありつつ(笑)も、クラウドコンピューティングの成長性はとてもよい技術的刺激になると考えています。
AWSの経験を積みたい方、是非ともリンクバルへよろしくお願いします!!


AWSの運用自動化サービス Cloud Automator で”攻め”のシステム運用 AMIMOTO スタック編 レポート


リンクバルの川畑です。先日サーバワークス様・デジタルキューブ様主催の「AWSの運用自動化サービス Cloud Automator で”攻め”のシステム運用 AMIMOTO スタック編」に参加しましたのでその内容をまとめました。

AWSの運用自動化サービス Cloud Automator で”攻め”のシステム運用 AMIMOTO スタック編

デジタルキューブ 小賀 浩通 / 堀家 隆弘 / 岡本秀高(40分+質疑応答)

はじめに
  • 本日のメインはあくまで「Cloud Automator」
  • Amimotoとは
    • WordPressがインストールされたAMI
    • AWS Marketplaceで提供
    • サーバ構成はEC2インスタンス1台からRDS(Aurora)まで対応
  • 事例紹介
    • Japantimes etc…
    • アメリカ・シンガポールでも
  • WordPressユーザーの目的は
    • コンテンツの公開!それ以上でもそれ以下でもない!
  • AMIMOTOを利用すればAWS上に数クリックで
    • ユーザーはビジネスに集中できる!
    • Amimotoの裏側はChef
    • ChefのコードはGitHubにも上がってるのでご自由に
WordPressの課題
  • AWSのスケーラビリティを最大限に発揮できない
    • WordPressの深い闇
  • 肥大化し続けるデータベースと大量のPluginによる密結合化で、メンテナンス不能状態
    • WordPressはオートスケールするシステムには向いていない
    • プラグインを入れれば入れるほどDB肥大化

プラグイン追加によりDB肥大化してしかも密結合パフォーマンスが遅くなって
とりあえず使っていないものを無効にしても、WordPress本体とプラグインが密結合で削除できない
この辺りはWordPressで運用しているシステム共通の問題でまさに深い闇!

WordPress課題の解決方法
1.JIN-KEI CloudFormationによるInfrastructure as Code with WordPress
  • 今までの構成は結局
    • EC2なので
      • AWSのサービス使えていない
      • 自動化できていない
  • マネージド・サービスの活用
    • AWSでは
      • RDS
      • S3
      • CloudFront
      • Certification Manager
      • etc…
  • CloudFormationで冪等性
    • マネージド・サービスをつかっても構築が複雑化してしまったら結局人力に依存
    • コードでリソースを定義
    • kumogataでユニット化(←便利そうなrubyのツール)
    • WPプラグイン連携も自動化
    • Amimotoで使用しているCloudFormationテンプレートはGitHubに公開している
    • そしてAWS MarketPlaiceにも公開している
2.MicroService
  • WordPressの問題点
    • ソースコードの肥大化
    • DBの肥大化
    • DBが単一障害点となる
    • Auto Scalingが無意味に
    • 機能とコア、テーマが密結合に
  • MicroSevicesによる疎結合の機能実装
    • システムを複数のコンポーネントで構築
    • コンポーネントはそれぞれ独立したシステム
    • RestfulAPIで疎結合
    • インフラメンテナンスからの解放
    • コスト最適化
  • 実際の事例
    • 検索の強化
      1. 全文検索の機能はない。単純なタイトルと本文のLike検索
      2. カスタムフィールドを検索た硫黄にカスタマイズすると急激に検索が遅くなるケール
      3. コンテンツの量に比例してDBの負荷があがる
    • Connector Plugin <-> Amazon Elasticsearch

WordPress本体とプラグインの間にConnector Pluginを挟むことで
RestfulAPIで疎結合といったMicroServiceを実現

ServerLessによる開発手法の変化
  • SeverLessとは
    • ssh接続の存在しない世界での開発、テスト、デプロイ
    • サーバサイドレンダリングからクライアントサイドレンダリングへ
    • 今までサーバが存在する前提で発展してきた開発手法が一切使えなくなる
  • AMIMOTOでは
    • AMIMOTOのユーザコンソールをServerLessで開発
      • Cognito
      • User Pools
      • ID Provider
      • ユーザデータの管理をAmazonがやってくれる(UserPool)
      • リマインダー
      • 他要素認証

ユーザーデータ管理をマネージド・サービスに任せられる
リマインダーや他要素認証も実装しなくてもよい
まだプレビュー版のようだけど正式版になって導入すれば幸せになれそう

  • ServerLess周りのテクノロジーの紹介
    • ServerLess Framework
      • AWS非公認(?)の海外のサービス
    • Riot.js
      • Viewに特化したUIライブラリ
      • プリコンパイルによるレンダリング
      • 軽量でコードが書きやすい
      • APIGatewayLambdaのアプリケーションのViewとして作りやすい
    • 堀家さんがいろいろ検証している
      • http://qiita.com/horike37
    • 目的があればサーバレスが使いやすい

おわりに

AWSマネージド・サービスによるServerLess化は常に情報をキャッチアップして積極的に導入していきたいと思いました。リンクバルはサーバエンジニアを積極募集中です。興味のある方は、ご応募ください。もちろん、社内の人間と面識があるのでしたら、直接にご連絡いただいてもかまいません。