Windows 10の PackageManagement を試してみた

WinObjCも大変気になるところですが、、
今日はWindows 10のパッケージマネージャのマネージャOneGet改めPackageManagementを試してみようと思います。
うまくすれば、構成管理ツールに組み込んでWindowsのセットアップを自動化できるかもしれません。

ちなみにGitHubはこちら
https://github.com/OneGet/oneget
ビルドするにはVisual Studioが必要ですが、Windows 10なら標準でインストールされています。

パッケージマネージャの準備

まずはパッケージマネージャにchocolateyを追加します。

おおよそ https://github.com/OneGet/oneget/wiki/cmdlets の手順の通りやればOKなのですが、
1点私がハマったのは、一見インストールが終わったように見えるのにインストールされていない問題。
デフォルトだとダウンロードしたインストールスクリプトの実行に失敗するように設定されているため、Set-ExecutionPolicy を実行して、署名付きであればダウンロードしたスクリプトは実行できるようにしておきましょう。
(ちなみにpowershellを管理者権限で実行する必要があります)

PS > Set-ExecutionPolicy RemoteSigned

パッケージをインストールする

代表的なパッケージがこちらに一覧されています。
https://chocolatey.org/packages

とりあえずAtomをインストールしてみましょう。

PS > Install-Package atom

Name                           Version          Source           Summary
----                           -------          ------           -------
Atom                           0.174.1          chocolatey       Atom: A hackable text editor for the 21st Century

これでインストール完了です。

install-package-atom

起動もバッチリでした。

Windows 10ことはじめ

遅ればせながらWindows10を愛用のSurface Pro 3にインストールしました。

インストールメディアはこちらから。
https://www.microsoft.com/ja-jp/software-download/windows10

無線LANでダウンロードしたのでインストール完了まで1時間程かかりました。

インストーラ画面

windows10_1

(マウスが写っちゃってる・・・)
windows10_4

新しい設定画面

windows10_6

新しいブラウザ Edge

Edge は思った以上に快適です。
そろそろブラウジング用途ではChromeをわざわざインストールする必要は無いかもしれませんね。
ただ、一つ気になったのは、高解像度モニタに合わせて表示すると、画像が拡大され、すこしぼけてしまう点。

windows10_8

Chromeはきれいに表示できるのですが、Edgeでは少しぼけて表示されました。
まあ私は気にならないのですが、人によっては嫌だという方もいらっしゃるのでは、という程度にはわかるレベルです。
設定画面にはそれらしい項目が見当たらず、軽く改善方法を探してみたのですが、情報が見つかりませんでした。
もしご存じの方がいらっしゃったら伺いたいところです。

Windows10については別途色々調査してみようと思います。

使いにくいScalaライブラリ

ScalaのHTTPライブラリってイケてないと思うんです。
何が気にくわないかというと、全体的にScalaのライブラリって、俺俺DSLを開発していて、
本当に使い方が分かりにくいと思うんです。

たとえば昔の Dispatch。(極端な例として、dispatch-classicのサンプルを記載します。)

// ex) http://dispatch-classic.databinder.net/URLs+and+Paths.html
import dispatch._
val sl = :/("www.scala-lang.org")
val learnScala = sl / "node" / "1305"

// ex) http://dispatch-classic.databinder.net/Response+Bodies.html
Http(learnScala >- { str =>
  str.length
})

もはやね。なんのこっちゃですよ。暗号ですか。
POSTリクエストを送りたくなってもどうしたらよいか全く想像がつきません。

私は、サンプルからオプションの使い方まで想像できるのが
使いやすいライブラリと考えています。

新しいDispatchではこのあたりは割と改善されているのですが、
ORMapperのSlick等も含めて、分かりにくい俺俺DSLを作り上げてしまうのはなんとかなりませんかね。
ライブラリの利用を通じて、タイプ量が少ない、Syntaxが短い事と、
シンプルで使いやすい事はイコールではない、ということを痛感しました。

AWS Lambdaで1分以上かかる処理をする

AWS Lambda、便利ですね。
サーバーレスでプログラムを実行できるのが魅力的なのですが、
実行時間が1分に制限される等、いくつかの制約で採用を見送る事もあるかと思います。

1分以上かかる処理はEC2等で実行しましょう、という事なのでしょうが、
どうしてもAWS Lambdaで処理させたい、というシチュエーションもあるかと思いますので、その制限を回避する方法を調査しました。

再帰呼び出しする

AWS Lambdaを起動するAPIが提供されているので、
LambdaスクリプトからLambdaを呼び出し、処理を引き継ぐことで、1分以上の処理を行うことができます。

var aws = require('aws-sdk')

exports.handler = function(event, context) {
  var count = event.count || 0
  count += 1
  console.log("count:" + count)
  
  // count が3を越えたら終了。
  if (3 < count) {
    console.log("count end.")
    context.succeed()
  } else {
    var lambda = new aws.Lambda()
    var params = {
      FunctionName: "recall",
      InvokeArgs: '{ "count": '+count+'}'
    }
    // countをパラメータに引き渡して自分自身のLambdaを再帰呼び出し。
    lambda.invokeAsync(params, function(err, data) {
      if (err) {
        console.log("error!")
        console.log(err)
      } else {
        console.log("next count:" + (count + 1))
      }
      context.succeed();
    })
  }
};

当然ながら、再帰実行する場合は、きちんと終了するフラグを立てるように実装しないと無限に再帰実行されます。
課金が発生するので、もしこの再帰Lambdaを実装する場合は慎重にテストしてください。
もし無限呼び出しが発生したら、Lambda関数の登録を削除する事で強制停止することは可能です。

また、Lambdaを実行するIAM Roleにlambda関係の権限を付与しておいてください。
(自動で作成されるlambda_basic_executionにはついていません。)

制約は多いものの、非常に安価にサーバーレスプログラムを実行することができるので、是非使っていきたいですね。

マイクロサービスの是非

巷ではマイクロサービスが流行っているようです。
モノシリックなアプリケーションに比べると、部分的なデプロイが容易になるなど、いくつかのメリットがあるようです。
すでに語られている内容ですが、個人的な見解をまとめておきます。

過去の経験としては、大規模になるにつれて、スケーラビリティや可用性を考慮すると、自然とマイクロサービスに近くなる気がします。
部分的にスケールアウトしたかったり、システム全体への影響のあるコード変更を避けたくなるからです。
多くの場合は以下のようなメリットを求めてマイクロサービスを採用するでしょう。

マイクロサービスのメリット

  • 部分的なスケールアウトを容易にしやすい。
  • コードの影響範囲を局所化してシンプルに保ちやすい。
  • 将来的に他のシステムから利用する可能性がある機能を切り出しておきたい。
  • 開発チームのパラレル化。

しかしちょっと待ってください。
一見、現代的な要求を満たしているマイクロサービスですが、
モノシリックなアプリケーションに比べると、多くのデメリットを潜在的に抱えています。

マイクロサービスのデメリット

  • 事前の設計如何によってコードが重複しやすい。
  • サービス間をまたがるリファクタリングがしにくい。
  • プロセス間通信によるオーバーヘッド。
  • 障害ポイントの増加→監視対象・運用作業の爆発。
  • デプロイ手順の複雑化。
  • テストの難度上昇。

特に運用面の問題は高確率で発生します。
モノシリックなアプリケーションに比べると設計の重要性はあがるでしょう。
(設計次第では、マイクロサービスのメリットを享受できない事もあるでしょうね)

本当の目的

個人的にマイクロサービス化するにあたり、重要だと考えているのは、以下の一点です。

  • システムの一部分が外部から利用される可能性があるのか。

「サービス」をマイクロ化しても、利用するのが同居するシステムのみの場合、
結局システム全体をデプロイするケースが多かったりして、あまりメリットが得られない事もあります。
マイクロサービスの採用を検討中の方は、この1点においてシンプルに考えてみても良いかもしれません。